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

[Lamont Granquist < >]

This is much better.  The FreeBSD port of the software is going to be 
named after the software so that they'll collide in the same way, so 
they have roughly the same problems.  The problem space here is also 
more similar to cookbooks since it is configuration management of an 
already written piece of software.

I'd still like to see more decentralized management of cookbooks to work 
around the problem of having "The XYZ" cookbook, though.  Still would 
like to see lots of supermarkets rather than just one, and would like to 
see different curated sets of cookbooks with different policies rather 
than just having one system of governance run by ChefInc for cookbooks.

At some point you're going to run into a cookbook author with a strong 
opinion that they're right who is willing to meet the requirements for 
cookbook maintenance and we're right back here.  It also puts ChefInc 
into the role of taking away cookbook authorship of "The XYZ" cookbook 
from existing authors, and that is going to lead to bad feelings on the 
part of someone, and invariably mistakes are going to be made, and angry 
twitter posts will be made.

Its possible we need to create that problem first before trying to solve 
it, though.

On Fri Jul 18 13:08:27 2014, Dreamcat4 wrote:
> 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 
> "
>  
> <mailto:
>  >",
>  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).