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

["steve ." < >]

Speaking as one of the people interested in running one of those big behind-the-firewall Supermarket instances, I definitely have a lot of these concerns in mind.

Ideally, I'd like for my Supermarket to proxy queries to the community one, which means namespacing would be a big problem for me right up front.  Without namespacing (in the cookbook name or as some kind of user/org prefix), distinguishing between BigCo's "java" cookbook and the community's "java" cookbook would be an issue.

We do also have the problem of orphaned cookbooks (and GitHub Enterprise repositories, for that matter) as people leave the company or their role/workload changes.  An opt-in or default policy of who takes responsibility for a cookbook once the original owner goes inactive (as determined by Curry noticing stale issues, maybe?) would be pretty cool.  Particularly because I think we'd like to distinguish between central-team-supported cookbooks, satellite-team-supported cookbooks and individually-shared cookbooks.  Each of those is likely to have a different level of support and it seems like shoppers should be able to easily distinguish between them while browsing cookbooks.

None of these is a deal breaker for me to run Supermarket but I'm happy to participate in community efforts to figure out and test possible solutions/implementations.

On Mon, Jul 21, 2014 at 9:40 AM, Adam Jacob < " target="_blank"> > wrote:

Lets get the governance of Chef straight, and then we can apply that model outside of core Chef if we need to.

Adam

On Sun, Jul 20, 2014 at 9:46 PM, Julian C. Dunn < " target="_blank"> > wrote:

On Fri, Jul 18, 2014 at 5:47 PM, Lamont Granquist < " target="_blank"> > wrote:

> 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.

I just don't really see that as realistic. Unless things are really on
fire in the ecosystem, who's going to bother standing up their own
Supermarket? People will say, really, I need to run my own
Rails/Postgres app to serve my version of "nodejs" because the
community couldn't straighten this out?

In reality, only people who want to share cookbooks among their peers
inside a company are likely to run their own Supermarket. And those
won't be public.

> 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.

*Someone* has to govern it. If not ChefCo, then who? At the moment,
there's no "community foundation" like the Fedora Project that
operates at some arms-length from RHT. And we invented a lot of this
ecosystem [1], so I would argue that by default it falls to ChefCo
(and I work here, so I'm pointing the finger at myself too).

At the moment, we're in a bad place, because ChefCo has insisted on
being hands off on this "governance" topic. We should be more
involved. Either that, or devolve governance to a governance body, a
committee, whatever. Issues like cookbook namespacing, namespace
squatting, etc. have smoldered for a long time precisely because we've
been directionless.

- Julian

[1] By which I mean the opscode-cookbooks, Chef itself, Supermarket,
and other tools around Chef

--
[ Julian C. Dunn < " target="_blank"> >          * Sorry, I'm    ]
[ WWW: http://www.aquezada.com/staff/julian    * only Web 1.0  ]
[ gopher://sdf.org/1/users/keymaker/           * compliant!    ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9       ]