Release to community site

[benlangfeld]

Important changes from #11 have been merged but as yet unreleased. I'd be very grateful if that could be rectified in good time.

[benlangfeld]

Is this cookbook in need of a co-maintainer? I'd be happy to help out if the current maintainer hasn't sufficient time.

[MichaelSp]

+1 please release new version

[gregkare]

Hi, is anything blocking a new release that contains stuff like #15? I would also be willing to help.

[benlangfeld]

@gregkare I honestly wouldn't hold up any hope for this. See further details on Twitter.

[gregkare]

@benlangfeld Thanks!

[JeanMertz]

Wow, thanks for that mention @benlangfeld . @poise that really should be added to the top of all the app* cookbooks. I just wasted 6 hours today...

Time to rm -rf and start over with my deploy script.

[benlangfeld]

Best to mention @coderanger if you want a response on that, @JeanMertz :)

[JeanMertz]

@benlangfeld Ah right, poise is an organisation with @coderanger in it 👍

Not that I want a reaction really, just sad that it is being discontinued, and that I "wasted" some time today. Having said that, switching over to the https://github.com/RiotGames/artifact-cookbook was very easy and I like its take on deployment processes.

[coderanger]

@JeanMertz Nothing is being discontinued, I'm just only focusing on bug fixes and maintenance. Until someone steps forward to financially support projects like this, I don't see how I have much of a choice.

I've not done a release to the community site mostly because I don't think there are any major bug fixes pending. I'll try to get one out later today, but in general you shouldn't expect new features until you want to sponsor them.

[JeanMertz]

@coderanger no problem. Your Twitter discussion does paint a different picture than what you just stated, but I can understand ideas and thoughts changing over a period of months.

I hope you find some way to continue working on the cookbook, I can see a lot of people using it.

[benlangfeld]

@coderanger You stated on Twitter that application* is deprecated and should be avoided. I think it would actually help to avoid frustration if a bolded note was added to the top of the README explaining this so people could make an informed decision about investing time, thus avoiding frustration like this from people wondering "why didn't you tell us it was dead?!".

As for "expecting new features [before] you want to sponsor them", that is not what is happening here. What is happening is people contributing features and being frustrated that they're not released. This is a common problem in open source, and in my experience more common in the Chef community than others. Everyone understands time constraints and I don't think anyone making a serious argument is actually against maintainers in any way, but there is a huge difference between those people who submit contributions and those who complain that maintainers don't fix bugs. There seems to be little recognition of this difference in the perpetual argument on these kind of situations and I think that's devaluing the entire ecosystem and causing rather than healing community frustrations which tend to stem from the idea of out-of-touch tyrannical maintainers who have an image of impeding progress. I'm not making any judgements against anyone here and I'm introducing scope-creep far beyond application*, but until we acknowledge and understand all sides of these situations instead of just lambasting one another we'll never have truly harmonious open-source communities.

Also, I've not seen many open source projects with a pay-to-merge policy, and that seems to be what you're hinting at. Clarification would be nice.