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