[chef-dev] Nodejs community CK mess


Chronological Thread 
  • From: < >
  • To:
  • Subject: [chef-dev] Nodejs community CK mess
  • Date: Fri, 18 Jul 2014 01:22:53 -0700 (PDT)

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.



Archive powered by MHonArc 2.6.16.

§