[chef] Re: Re: Community cookbook maintenance (was: Re: Reprepro cookbook)

[Ranjib Dey < >]

yes there is a lot of value with Chef inc, providing a public supermarket instance, it seeds community effort. You dont need it if you consume cookbooks from github or other sources (can be public, can be private/org specific). 

why should community maintainers maintain a cookbook? - many. and i dont see the different of this with ruby gem, or any userspace tool (pyhton egg, or a debian in ppa).  But the common reasons are: 1) you dont want to reinvent wheel,. if theres no opensource cookbook on ossec, every time i join a place it allows me rapidly roll out ossec cookboook. 2) my job depends on my skills/knowledge, to get a better job, i need to improve my skill. but that not possible if theres no one to mentor inside my own org. opensource brings that possibility. again this is not specific to chef, its very opensource thing, if you dont understand it, or dont know what value you get, dont do it. but for those of us, who are outside chef, uses it, and loves it. exposure is a huge thing, i cant become oracle reporting expert, but i can become chef expert even if dont have much money.

the last statement you made regarding namespace, is a technical problem. again its no different here than any other place. for example redhat has libvirt-lxc which everyone confuses with standard LXC but the project itself has little code/feature compatibility with main LXC. The point is like namespace is perceived, if you want you can publish a cookbook with samename and if its really good (and assuming theres enough people who wants it) you can definitely outweigh the other cookbook. if thats not happening, lets address that.

the definition of critical is very diverse, theres no common critical component/cookbook. nothing. 0. as far as the whole community is concerned. if you freeze platform  (since chef run from windows machine to raspberry pi to AIX to solaris) you might get a list of critical cookbooks (like sudo will be for linux), you might get another layer on family (like sysdtemd on ubuntu 15.04) .. we are in process of establishing the family specific maintainers, a similar effort can be made for cookbooks as well.. but will be mostly community and few core contributors .. similar to kernel and userspace..  linus and linux foundation or redhat does not maintain ruby specific rpm etc..

i am very interested in addressing this.. please keep your thoughts pouring :-) , but understand we cant solve it in a click, its gonna take some time, we have to keep talking, and out collaborative efforts on the next blockers toward this direction.

fwiw i am the LT of chef on ubuntu, and i am working on a CD system that will test actual community cookbooks on every master merge of chef. Which will greatly reduce the maintenance burden, cause now core devs can also see what affect the changeset has. Next step will be do a survey and get a list of cookbooks and interested folks (brigade as we calling it) for ubuntu. What i wonder is a common pool might not make sense, though Chef is cross platform, majority of cookbook is not.

hth

ranjib

On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz < " target="_blank"> > wrote:

> Am 22.06.2015 um 22:52 schrieb Julian C. Dunn < "> >:
>
> On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob < "> > wrote:
>
>> 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?
>
> Hey Adam,
>
> Would we consider transferring some of those cookbooks our of
> {opscode,chef}-cookbooks to a community-organized org like
> chef-brigade (https://github.com/chef-brigade) or redguide
> (https://github.com/redguide) for better maintenance? What would be
> the preconditions to doing that?
>
> Personally I would like the chef-brigade and redguide to be merged,
> but I do not remember all the players involved -- if they are on this
> list perhaps they can speak up.


How would this prevent the problems that happend with the last migration of former opscode-cookbooks to community maintainers?

Why should community maintainers care about the cookbooks in the future?
It can be a time consuming burden and people need to pay their rent and do their regular jobs…

I know, this will be very provoking, but:

If Chef, inc. doesn't want to maintain even critical cookbooks anymore, is there still a valid reason for running a public Supermarket site?
If you go the "libertarian way" there is no reason for a supermarket site to protect/block names of cookbooks anymore that prevents users to pick other, maybe better community resources over legacy-cookbooks that are mentioned in guides and examples.

Either you (Chef, Inc.) control the market (e.g. maintain critical things yourself) or you should allow the free market (=community) to compete against each other based on equal opportunity (= namespaces or no supermarket). Everything else/in between will just end in chaos and anarchy.

regards
Roland