[chef-dev] Re: Re: Re: Re: Re: Nodejs community CK mess

[Dreamcat4 < >]

On Fri, Jul 18, 2014 at 8:02 PM, Daniel DeLeo < " target="_blank"> > wrote:

I think the proposal is that anyone can post whatever they like in their own namespace. If you want your cookbook to be THE cookbook named “apache2” or “nodejs” cookbook, then you opt-in to a certain governance model or set of standards,

This idea is vaguely similar to FreeBSD ports in the sense that anybody can create their own ports using full power of FreeBSD's ports build environment. And without any oversight requirement.

However the difference is that with FreeBSD, to get into the official hosted repository requires some procedure. The port itself (or the maintainer) must be adherent to those practices and guidelines laid out "FreeBSD Porter's Handbook". Which include some formatting conventions, and a checklist for testing that the port complies, builds OK etc. But thankfully for newcomers it isn't too hard to pick up.

Also recently on FreeBSD, we have now got Redports.org which is some jenkins CI build farm to auto-test that ports will build and install correctly. As does Ubuntu's Launchpad.net have it's own CI build / test farm for .deb package maintainers.

 

and if you don’t meet the standards then the top-level name can be taken away.

FreeBSD has some "auto lease" mechanism. Whereby the maintainership of a port will automatically failover back to " "> ", but only IF the current port maintainer has not responded to open bug or version update request after 90 days. Which is 1 quarter. This policy seems to work. It's not "too harsh" or "asking too much". But just enough to ensure that the namespace can become available again for others to take over in future.

I don't think anybody is saying that "supermarket should do this" or "do that" because "that other project does it that way". However as a more resource - limited group, then it can save time pick and choose some of the little stuff from others, if are confident in feeling that it will probably work just as well for chef / supermarket too.

SO

Don't entirely disregard a look at the procedures for OSes and their package management systems entirely. Just because they are not in the same category as chef / supermarket. There may be overlap found in some certain areas. (just not others).

I personally don’t think there should be any requirement to post stuff on the supermarket site other than it not being actively malicious (modulo some legal business, like your license has to allow people to download it and use it, maybe).

--
Daniel DeLeo

On Friday, July 18, 2014 at 11:44 AM, Cameron Cope wrote:

> What do you think about making that governance model a requirement for listing cookbooks on the official Supermarket site? It could help reduce confusion in the community if there were a 1:1:1 relationship of supermarket:namespace:government.
>
> -Cam
>

> On Fri, Jul 18, 2014 at 2:34 PM, Adam Jacob < "> (mailto: "> )> wrote:
> > We're actively in the process of deciding how we maintain things for Chef proper. Once that is done, I would propose we could look at doing something that basically allows people to "opt-in" to that governance model - where, for example, the author of a community cookbook who intends for it to be "canonical" can choose to adopt the "normal" Chef governance model, and hence have mechanisms for dealing with these cases.
> >
> > We could then mark cookbooks that have opted in. While it wouldn't make any statements about quality, it would tell you precisely which ones have a stricter central governance model.
> >
> > Adam
> >
> >

> > On Fri, Jul 18, 2014 at 11:22 AM, Cameron Cope < "> (mailto: "> )> wrote:
> > > I've heard the statement several times that Chef Software doesn't want to act like a dictator, but it seems tome that the community wants some sort of leadership and organization. I agree that looking at other examples for namespacing might help, but don't just look at the technical details of those systems, research how OSS communities organize and govern themselves. I highly recommend looking at governance in Debian, Ubuntu, and the Apache Foundation. As the corporate backer of Chef, I think it's perfectly reasonable for you guys to decide what your governance model is and how much control your have.
> > >
> > > http://oss-watch.ac.uk/resources/governancemodels
> > > https://www.debian.org/devel/constitution
> > > http://www.ubuntu.com/about/about-ubuntu/governance
> > > http://www.apache.org/foundation/how-it-works.html
> > >
> > > -Cam
> > >

> > > On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber < "> (mailto: "> )> wrote:
> > > > I think this is a great example of something we need to address…
> > > >
> > > > With that said, I have more questions than answers.
> > > >
> > > > The first thing I would do is look to how other communities and package repositories handle this issue. I am on vacation right now and won’t have a chance to do the research myself until I get back, but I really would love to see a good example of how this is handled elsewhere. How do CPAN, NPM, RubyGems, etc handle this?
> > > >
> > > > On a technical level, I think there are a lot more questions that have to be answered. Some of them that come to mind would be:
> > > >
> > > > If we transfer the name to someone else:
> > > > - What requirement do they have to maintain legacy code?
> > > > - What is the expectation around breaking or not breaking the API the cookbook provides, especially if SemVer isn’t in use?
> > > > - Does the license on the old cookbook allow for it to even be maintained?
> > > >
> > > > Since we have talked a lot about namespacing, how would that change this equation? Does it actually solve the problem we are trying to solve? Has it played out that way in other communities that use namespacing like Docker or the Puppet Forge?
> > > >
> > > > The biggest problem in all of this… Who gets to be the decider? How do we do this in a fair manner? It is easy to look at code and have the attitude this sucks, mine is better, but it is much harder to have to explain to someone that this person or group has decided to take a thing away from them. My personal fear is that we discount the people side of this situation. People and feelings are a wicked hard problem set and there really is no good answer. But, as we move forward with any discussion around this, I would love to hear how people think we should handle this part of the equation.
> > > >
> > > > For me, the biggest thing I don’t want to see is Chef Software become the decider and ruler. I want to see it be the community that comes together around a set of values and a process for governance. While I think it is important that Chef Software have a seat at the table and that they take on the responsibility of running the site, I don’t think Chef Software should have the end all say in how we govern things.
> > > >
> > > > Just my 2 cents.
> > > >
> > > > — cwebber
> > > >

> > > > On Jul 18, 2014, at 4:22 AM, < "> (mailto: "> )> < "> (mailto: "> )> wrote:
> > > >
> > > > > Ohai everyone!
> > > > >
> > > > > We wanted to report an academic example of cookbook governance issues. Hoping
> > > > > this will further the subject.
> > > > >
> > > > > As everyone know, nodejs is really popular and many of you want to deploy it
> > > > > for production (maybe with npm packages too).
> > > > > For now a simple search on supermarket give us:
> > > > > - node
> > > > > - nodejs
> > > > > - npm
> > > > > - node-windows
> > > > >
> > > > > And we may lack some.
> > > > > Moreover, none of them have enough quality and tests for a real production
> > > > > proof system.
> > > > >
> > > > > With our experience, we're trying to rebuild a new cookbook with experience of
> > > > > each other.
> > > > > Discussion begins here: https://github.com/balbeko/chef-npm/pull/26
> > > > > To federate all this dev, we created a collaborative organization "REDGUIDE"
> > > > > (https://github.com/redguide) and started fusion and improvement from existing
> > > > > work.
> > > > >
> > > > > This cookbook (available here: https://github.com/redguide/nodejs ) is now
> > > > > really good regarding to current chef practices. It also started to be widely
> > > > > used and known by the community.
> > > > >
> > > > > Final step: publishing it...
> > > > > Here come problems: https://github.com/redguide/nodejs/issues/9
> > > > >
> > > > > TL;DR : Previous maintainer want to keep control over cookbook and to keep it
> > > > > under his name despite the fact that it is no longer open, active and
> > > > > responsive on this CK
> > > > > (https://github.com/mdxp/nodejs-cookbook/issues?state=open).
> > > > >
> > > > > This decision is really painful for everyone, it blocks all good things done by
> > > > > community (and block application_nodejs to use it as "depends" for example).
> > > > >
> > > > > NEXT:
> > > > > - For this project:
> > > > > - Press nodejs maintainer to accept the merge and release his control
> > > > > over community repo (community work belong to the community)
> > > > > - Creating a yet-another-nodejs cookbook? (or better nodejs-ii, as we
> > > > > can see for timezone and timezone-ii)
> > > > > - Destitute maintainer of his role on supermarket (never a good news to
> > > > > do this)
> > > > > - For chef:
> > > > > We really have to manage this kind of case in supermarket. The main
> > > > > risk is that people/company who are using community cookbooks stop trusting
> > > > > community work anymore, and start writing as much fork/copy (either public or
> > > > > private) of the same work. Community work would be severely affected by this.
> > > > > This is not the way we think Chef should be.
> > > > >
> > > > > Our proposition (but must be debated):
> > > > > - When someone create a new cookbook on supermarket, a new github repo is
> > > > > created (like https://github.com/jenkinsci/ do).
> > > > > - It prevent git erase / modification.
> > > > > - This repo became the new "central point" for community issues /
> > > > > contributions as it doesn't belong to someone in particular, governancy can be
> > > > > edicted by getchef/community.
> > > > >
> > > > > We also can provide test platform (for TK for example) easily.