My overall experience with Chef isn't that great, because seems to me their team didn't response to users'issue seriously.
E.g. I have reported a bug [1] half year ago that the chef-server failed to start automatically when your server restart, still mark as `Unresolved` and no official answer from chef.
I think when your server startup script failed to work on a major distribution like Ubuntu, it should be considered as critical, right?
I'm sorry you feel that you didn't have a good experience.
As one of the original Chef contributors before Opscode, and then becoming one of the lead people working with the open source community for Opscode, the vitality of the open source Chef project is very important to me. However, Opscode's support for all of our open source projects also hinges on the company being successful enough to continue to do so. Thus, a balance must be struck.
Opscode doesn't respond to every ticket on that open source tracker, just like we don't write all of the code in the open source project. I personally try to at least see every issue, but with over 1.8 million installs of the Chef gem alone, there are a lot of users out there. If you want a guaranteed response, we do have various paid support plans which will provide you with that, but it doesn't come for free because we have to pay the people who research and write those responses.
There are multiple ways to install the Chef 10 Server and many ways to start the processes. We have tried to support the most popular, and I think most people have found success. We're proud that we can do things like release our rewrite of the Chef Server in erlang back to open source. We want it to be easy for people to use Chef. We initially wrote it to make our lives easier, and we want your lives to be easier too. That's why the Chef 11 Server ships in our Omnibus packaging, which provides a running Chef Server in three commands or less.
Firstly, thanks for your reply and your works on chef. I really appreciate it.
I think there is a difference between people who want free support & people who document a bug of a opensource project clearly in the hope of to improve the quality of that project - I hope I am in the latter case.
My reported issue can be easily fixed with some hacky workarounds, so I didn't bother with it and move on (As you can see I have never comment on that ticket). However, I still decided to create that ticket because I think the issue is easy to reproduce and will affect a lot of new comers to chef.
The issue is confirmed by others as well, one awesome commenter Florin Mihaila even provided a very detail analyse and solution to the issue.
For me, I would prefer if you can close the ticket if you think it is invalid, or mark as don't fix if resource is not allowed, rather than leaving as open and unanswered.
Of course, this is your project so I can't disagree with your preference, thanks anyway :)
Always appreciate bugs being filed. I did a little pondering on the ticket the other day. Since we're using update-rc.d, we're likely talking about debian package install, which means that we could probably set the defaults correctly with update-rc.d, someone just needs to do the research and patch the init scripts or the debian packaging. So it's best for the bug to be open.
Depressingly their competitors are no better. I've been monitoring a bug in puppet that's been open for the better part of three years for adding options like "--enablerepo" to yum invocations. This is not technically difficult to do but they keep dithering on design issues "because it's not cross platform". (Really? Because Ubuntu and RedHat totally agree on how to name packages, where system files live, which init.d to use, and those are both Linuxes; it gets even stupider with Solaris, BSD and Windows)
E.g. I have reported a bug [1] half year ago that the chef-server failed to start automatically when your server restart, still mark as `Unresolved` and no official answer from chef.
I think when your server startup script failed to work on a major distribution like Ubuntu, it should be considered as critical, right?
[1] http://tickets.opscode.com/browse/CHEF-3204