[chef] Re: Re: Reprepro cookbook

[Adam Jacob < >]

Hi Roland. I think the willingness to adopt new maintainers isn't true in the main, while maintainer activity most certainly is. We (Chef Software) have been pretty aggressively trying to find new maintainers for much of the community cookbooks we started - not because we don't see value in them, but because we (often) are no longer direct users of the technology in question, and so we wind up not being the best possible maintainers. That process started well over a year ago, and continues.

I think it's clear that, over the seven years Chef has existed, the role of community cookbooks has changed and morphed several times. We initially all believed that we would wind up with a single, glorious abstraction for each piece of software we needed to manage - I think in the intervening time we've learned that's not realistic, and where it is, the shape is different (more resources, less recipes). You can see reflections of that in the way we teach Chef - we used to start with using community cookbooks, and then try and teach how it worked - we now teach how it works first, and build up to re-use as an advanced topic. What used to happen was people would get a great initial experience with a cookbook, then need to make a small change or variation, and wind up lost in a sea of complexity. That happens today, too, but less often than it used to.

To speak for Chef Software directly, we have always had people on staff whose role was assisting the creation and maintenance of cookbooks. That number has fluctuated up and down over time, with the skill sets of people we hire, and the normal day-to-day ebb and flow of trying to figure out how to build a business that is successful. We have people on staff today who do the same. What is clear is that the energy around cookbooks in the community is far greater than the energy we can muster as an organization (regardless of how much capital we do or do not have - y'all outnumber us) - and so our focus today is on trying to build and support the best community we can, through development of the supermarket, better tooling, and providing a few key examples of how best to build a community cookbook (see Sean's work on the httpd cookbook.)

Perhaps we need to organize a PR/merge festival brigade?

Best,

Adam

On Sun, Jun 21, 2015 at 5:40 AM, Roland Moriz < " target="_blank"> > wrote:

Am 21.06.2015 um 10:04 schrieb Sean OMeara < " target="_blank"> >:

Documentation PRs are super easy to merge, too.  They don't require
tests, just human parsing.
Totally my fave.
-s

There are many cases of (former) opscode-cookbooks that have such „easy“ PRs waiting but wont get merged - for months.

IMHO most cookbooks don’t lack PRs and issue reports but maintainer activity or willingness to adopt new maintainers if the current ones don’t have enough time or motivation anymore (which is fine, it’s OSS and shouldn’t be a burden). 

For example you may want to check your github notifications on the nginx cookbook (afaik you’re co-mainainer). I’ve worked through many open, unanswered issues last week to help users. Because  I’m not a maintainer

I cannot close issues or merge PRs so my efforts can’t bring any sustainable improvement. 

That’s why I can fully understand that many chef users become angry and or leaving chef behind.

See also: 

https://feedback.chef.io/forums/301644-chef-product-feedback/suggestions/8386914-broken-cookbook-community

I clearly don’t understand Chef, inc. here… and I’m getting humiliated by Ansible users regularly when I try to present Chef :-(

regards

Roland