Hi,Am 23.06.2015 um 00:23 schrieb Ranjib Dey < " target="_blank"> >: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).I don’t think that it seeds community effort, because it’s often a „trap“. A cookbook, e.g. named `systemd`, looks legit but it may be broken, outdated or just be a no-op cookbook that reserves the name:- number of downloads is irrelevant, as we all know- follower number is also not a good indication, because even after a year, supermarket did not get the traction of e.g. github- last release date is probably the best indicator. In my experience most cookbooks that are not updated within the last 12 months are outdated, e.g. won’t work with the recent distros like Debian 8 or CentOS/RHEL 7. How should starters „know“ this?Imagine a rather new chef user that needs to deal with systemd unit files. Just with that single „trap" he/she will probably lose a couple of hours or days or give up and pick something else with batteries included.I’m sure this is not intentional and everyone had the best intentions doing it the current way - but IMHO it’s broken :-/IMHO it’s all about hitting the right spot in between of „too much“ and „too little“ and the original opscode-cookbooks concept was probably a „too much“-problem and today it looks like we’re in a „too little“ situation.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.Sorry, but that doesn’t answer my question. Many open source projects start, when something (technology, framework) becomes „hot“. Everyone is trying to learn and get a spot in the eco system. Popularity usually also means a rising number of jobs, e.g. people can get their OSS contribution funded and/or get an interesting job. However this strategy starts to collapse when the crowd moves on to „even hotter“ things (typical hype lifecycle).Example 1: now outdated Ruby gems -> maintainer moved to node -> now outdated npm modules -> maintainer moved to Go.Example 2: cfengine -> puppet -> chef -> ansible -> dockerThis brain-drain affects not only the quantity but also the quality of projects. Less „eyes“ to find bugs, less „hands“ to fix them, less users to use it. Experience for new users will suffer.Why should people contribute to $not_hot_anymore projects? I don’t see that many unique chef-jobs, so having something in the GitHub repo/CV doesn’t bring you new opportunities by itself.Even a popular (>200 stars on GH) knife plugin for some trending and cheap cloud hosting provider brings you exactly 0 job/project offers (btdt).possible options:- provide minimal services that work out of the box by yourself (Chef, Inc)- subsidize community to maintain it (you pay, you decide how)- offer opportunities so people can benefit from supporting the community (e.g. job site, contract projects, sales-partnerships with indies)otoh: As far as I can see, most „Chef certified partners“ listed on https://www.chef.io/partners/#find-a-partner are not part of the community and some companies that provide value to the community are not listed there at all…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.Your libvirt-example is great, as it shows why nearly nobody used it and why Docker has such a huge impact by just providing a fancy way to distribute tar archives and wrap some syscalls ;) (oversimplification intentional)Redhat isn’t very good in community/relationship outside of their own Fedora/RHEL area. Just see how they „sell“ systemd to users, developers and admins. I think better tutorials and community-relations would have prevented that hatery/shitstorm against it.When I talk to systemd-"haters", I ask them to write me a sysv-init script for a service, then I show them the systemd unit representation.When ansible users talk to me (chef user), they ask me to write a solution that… whops. damn. You understand what I mean?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..Why do people need DevOps? To have a reliable infrastructure to provide services that make money and to stay competitive. Usually that involves more or less custom applications based on common frameworks/stacks that need to be deployed. So at least a couple of application deployment stacks are critical to show the benefits of a DevOps solution. Even the learn.chef.io tutorial falls apart, when you’re using the latest releases of cookbooks used in the tutorial, so this is also a good definition of critical.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.You don’t need a fancy distro/edge-case. Just make sure Debian 8, RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t mean something like „it installs runit triggered by sysv-init — and it still works…“ on a systemd distro ;-)regardsRolandPS: Despite all my examples I’m not a systemd zealot. I was okay with upstart… But a common base of various distros is a good thing for everyone in the long run. And it’s also a good example for a game-changer and about the agility/adoption capabilities of such things.hthranjibOn Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz < " target="_blank"> > wrote:
> Am 22.06.2015 um 22:52 schrieb Julian C. Dunn < " target="_blank"> >:
>
> On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob < " target="_blank"> > 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
Archive powered by MHonArc 2.6.16.