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

[Noah Kantrowitz < >]

As someone that helps run PyPI, we only take action against a package 
(transferring ownership, removal) either with the written consent of the 
current owner or with proof of an imminent threat (package is malicious or 
otherwise puts users at risk). Every now and then we'll get copyright trolls, 
but its maybe once every 2-3 years. Once someone camps a name, thats pretty 
much the end of it, first come first served.

--Noah

On Jul 18, 2014, at 4:52 AM, Christopher Webber 
<
 >
 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, 
> <
 >
>  
> <
 >
>  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.
>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail