Nodejs community CK mess


#1

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.


#2

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, bvessemont@gmail.com bvessemont@gmail.com 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.


#3

I’ve heard the statement several times that Chef Software doesn’t want to
act like a dictator, but it seems tome that the community wants some sort
of leadership and organization. I agree that looking at other examples for
namespacing might help, but don’t just look at the technical details of
those systems, research how OSS communities organize and govern themselves.
I highly recommend looking at governance in Debian, Ubuntu, and the Apache
Foundation. As the corporate backer of Chef, I think it’s perfectly
reasonable for you guys to decide what your governance model is and how
much control your have.

http://oss-watch.ac.uk/resources/governancemodels
https://www.debian.org/devel/constitution
http://www.ubuntu.com/about/about-ubuntu/governance
http://www.apache.org/foundation/how-it-works.html

-Cam

On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber cwebber@getchef.com
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, bvessemont@gmail.com bvessemont@gmail.com
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.


#4

We’re actively in the process of deciding how we maintain things for Chef
proper. Once that is done, I would propose we could look at doing something
that basically allows people to “opt-in” to that governance model - where,
for example, the author of a community cookbook who intends for it to be
"canonical" can choose to adopt the “normal” Chef governance model, and
hence have mechanisms for dealing with these cases.

We could then mark cookbooks that have opted in. While it wouldn’t make any
statements about quality, it would tell you precisely which ones have a
stricter central governance model.

Adam

On Fri, Jul 18, 2014 at 11:22 AM, Cameron Cope chef@camcope.me wrote:

I’ve heard the statement several times that Chef Software doesn’t want to
act like a dictator, but it seems tome that the community wants some sort
of leadership and organization. I agree that looking at other examples for
namespacing might help, but don’t just look at the technical details of
those systems, research how OSS communities organize and govern themselves.
I highly recommend looking at governance in Debian, Ubuntu, and the Apache
Foundation. As the corporate backer of Chef, I think it’s perfectly
reasonable for you guys to decide what your governance model is and how
much control your have.

http://oss-watch.ac.uk/resources/governancemodels
https://www.debian.org/devel/constitution
http://www.ubuntu.com/about/about-ubuntu/governance
http://www.apache.org/foundation/how-it-works.html

-Cam

On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber cwebber@getchef.com
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, bvessemont@gmail.com bvessemont@gmail.com
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.


#5

What do you think about making that governance model a requirement for
listing cookbooks on the official Supermarket site? It could help reduce
confusion in the community if there were a 1:1:1 relationship of
supermarket:namespace:government.

-Cam

On Fri, Jul 18, 2014 at 2:34 PM, Adam Jacob adam@getchef.com wrote:

We’re actively in the process of deciding how we maintain things for Chef
proper. Once that is done, I would propose we could look at doing something
that basically allows people to “opt-in” to that governance model - where,
for example, the author of a community cookbook who intends for it to be
"canonical" can choose to adopt the “normal” Chef governance model, and
hence have mechanisms for dealing with these cases.

We could then mark cookbooks that have opted in. While it wouldn’t make
any statements about quality, it would tell you precisely which ones have a
stricter central governance model.

Adam

On Fri, Jul 18, 2014 at 11:22 AM, Cameron Cope chef@camcope.me wrote:

I’ve heard the statement several times that Chef Software doesn’t want to
act like a dictator, but it seems tome that the community wants some sort
of leadership and organization. I agree that looking at other examples for
namespacing might help, but don’t just look at the technical details of
those systems, research how OSS communities organize and govern themselves.
I highly recommend looking at governance in Debian, Ubuntu, and the Apache
Foundation. As the corporate backer of Chef, I think it’s perfectly
reasonable for you guys to decide what your governance model is and how
much control your have.

http://oss-watch.ac.uk/resources/governancemodels
https://www.debian.org/devel/constitution
http://www.ubuntu.com/about/about-ubuntu/governance
http://www.apache.org/foundation/how-it-works.html

-Cam

On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber cwebber@getchef.com
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, bvessemont@gmail.com <
bvessemont@gmail.com> 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.


#6

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 cwebber@getchef.com 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, bvessemont@gmail.com bvessemont@gmail.com 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.


#7

On Fri, Jul 18, 2014 at 7:22 PM, Cameron Cope chef@camcope.me wrote:

I’ve heard the statement several times that Chef Software doesn’t want to
act like a dictator, but it seems tome that the community wants some sort
of leadership and organization. I agree that looking at other examples for
namespacing might help, but don’t just look at the technical details of
those systems, research how OSS communities organize and govern themselves.
I highly recommend looking at governance in Debian, Ubuntu, and the Apache
Foundation. As the corporate backer of Chef, I think it’s perfectly
reasonable for you guys to decide what your governance model is and how
much control your have.

http://oss-watch.ac.uk/resources/governancemodels
https://www.debian.org/devel/constitution
http://www.ubuntu.com/about/about-ubuntu/governance
http://www.apache.org/foundation/how-it-works.html

I think you can also add FreeBSD to that list. Because in some ways, a chef
cookbook can feel be a bit similar like a “FreeBSD Port”. In that respect I
can state that my recent experience (for creating a new FreeBSD port and
submitting it officially) was very positive one.

But you know, in other ways its very different too. The Chef community does
not have so many 1000’s members manpower than an operating system. For
commiters, maintainers, etc it all takes extra work and time for such kinds
of oversight.

A Chef solution cannot be so demanding for resources. Heh, maybe Github has
since added some new (relevant) features for Organisation, or they may do
so in the future.

-Cam

On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber cwebber@getchef.com
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, bvessemont@gmail.com bvessemont@gmail.com
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.


#8

-Inf, I wouldn’t want Chef Inc having any formal control over governance of my code, nor is my code a democracy, and I would like my stuff to be listed as existing. Supermarket is a sharing site, it should not have strong opinions like this.

–Noah

On Jul 18, 2014, at 11:44 AM, Cameron Cope chef@camcope.me wrote:

What do you think about making that governance model a requirement for listing cookbooks on the official Supermarket site? It could help reduce confusion in the community if there were a 1:1:1 relationship of supermarket:namespace:government.

-Cam

On Fri, Jul 18, 2014 at 2:34 PM, Adam Jacob adam@getchef.com wrote:
We’re actively in the process of deciding how we maintain things for Chef proper. Once that is done, I would propose we could look at doing something that basically allows people to “opt-in” to that governance model - where, for example, the author of a community cookbook who intends for it to be “canonical” can choose to adopt the “normal” Chef governance model, and hence have mechanisms for dealing with these cases.

We could then mark cookbooks that have opted in. While it wouldn’t make any statements about quality, it would tell you precisely which ones have a stricter central governance model.

Adam

On Fri, Jul 18, 2014 at 11:22 AM, Cameron Cope chef@camcope.me wrote:
I’ve heard the statement several times that Chef Software doesn’t want to act like a dictator, but it seems tome that the community wants some sort of leadership and organization. I agree that looking at other examples for namespacing might help, but don’t just look at the technical details of those systems, research how OSS communities organize and govern themselves. I highly recommend looking at governance in Debian, Ubuntu, and the Apache Foundation. As the corporate backer of Chef, I think it’s perfectly reasonable for you guys to decide what your governance model is and how much control your have.

http://oss-watch.ac.uk/resources/governancemodels
https://www.debian.org/devel/constitution
http://www.ubuntu.com/about/about-ubuntu/governance
http://www.apache.org/foundation/how-it-works.html

-Cam

On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber cwebber@getchef.com 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, bvessemont@gmail.com bvessemont@gmail.com 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.


#9

But supermarket is also open source, so anyone could run their own with
their own cookbooks and policies. I have been sort of curious about the
application of more than one supermarket up to this point. If
discoverability is a concern, then maybe an index of supermarkets? Or…
just implement the concept of (channels||repositories||namespaces) within
supermarket, and have info in each namespace on how it is managed.

On Fri, Jul 18, 2014 at 2:47 PM, Noah Kantrowitz noah@coderanger.net
wrote:

-Inf, I wouldn’t want Chef Inc having any formal control over governance
of my code, nor is my code a democracy, and I would like my stuff to be
listed as existing. Supermarket is a sharing site, it should not have
strong opinions like this.

–Noah

On Jul 18, 2014, at 11:44 AM, Cameron Cope chef@camcope.me wrote:

What do you think about making that governance model a requirement for
listing cookbooks on the official Supermarket site? It could help reduce
confusion in the community if there were a 1:1:1 relationship of
supermarket:namespace:government.

-Cam

On Fri, Jul 18, 2014 at 2:34 PM, Adam Jacob adam@getchef.com wrote:
We’re actively in the process of deciding how we maintain things for
Chef proper. Once that is done, I would propose we could look at doing
something that basically allows people to “opt-in” to that governance model

  • where, for example, the author of a community cookbook who intends for it
    to be “canonical” can choose to adopt the “normal” Chef governance model,
    and hence have mechanisms for dealing with these cases.

We could then mark cookbooks that have opted in. While it wouldn’t make
any statements about quality, it would tell you precisely which ones have a
stricter central governance model.

Adam

On Fri, Jul 18, 2014 at 11:22 AM, Cameron Cope chef@camcope.me wrote:
I’ve heard the statement several times that Chef Software doesn’t want
to act like a dictator, but it seems tome that the community wants some
sort of leadership and organization. I agree that looking at other examples
for namespacing might help, but don’t just look at the technical details of
those systems, research how OSS communities organize and govern themselves.
I highly recommend looking at governance in Debian, Ubuntu, and the Apache
Foundation. As the corporate backer of Chef, I think it’s perfectly
reasonable for you guys to decide what your governance model is and how
much control your have.

http://oss-watch.ac.uk/resources/governancemodels
https://www.debian.org/devel/constitution
http://www.ubuntu.com/about/about-ubuntu/governance
http://www.apache.org/foundation/how-it-works.html

-Cam

On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber cwebber@getchef.com
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, bvessemont@gmail.com <
bvessemont@gmail.com> 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.


#10

The relationship between Chef and the Supermarket has always been that of a programming language to an artifact repository. Chef is to Supermarket as Java is to Maven, as Ruby is to rubygems, as Python is to PyPI, as Node is to NPM, etc.

A Linux or Unix distribution’s packaging policies represent a curation of existing software, which is something else entirely. They usually have rigid rules around them. Maintenance of an RPM spec is very different than maintenance of a piece of living software.

A “cookbook distribution” is an interesting idea. Maybe we’ll see those start to pop up.

We do need a governance model to take care of hit-by-a-bus problems or malicious code as Noah described.

Happy to keep this discussion going!

-s

Sent from Mailbox

On Fri, Jul 18, 2014 at 1:46 PM, Dreamcat4 dreamcat4@gmail.com wrote:

On Fri, Jul 18, 2014 at 7:22 PM, Cameron Cope chef@camcope.me wrote:

I’ve heard the statement several times that Chef Software doesn’t want to
act like a dictator, but it seems tome that the community wants some sort
of leadership and organization. I agree that looking at other examples for
namespacing might help, but don’t just look at the technical details of
those systems, research how OSS communities organize and govern themselves.
I highly recommend looking at governance in Debian, Ubuntu, and the Apache
Foundation. As the corporate backer of Chef, I think it’s perfectly
reasonable for you guys to decide what your governance model is and how
much control your have.

http://oss-watch.ac.uk/resources/governancemodels
https://www.debian.org/devel/constitution
http://www.ubuntu.com/about/about-ubuntu/governance
http://www.apache.org/foundation/how-it-works.html

I think you can also add FreeBSD to that list. Because in some ways, a chef
cookbook can feel be a bit similar like a “FreeBSD Port”. In that respect I
can state that my recent experience (for creating a new FreeBSD port and
submitting it officially) was very positive one.
But you know, in other ways its very different too. The Chef community does
not have so many 1000’s members manpower than an operating system. For
commiters, maintainers, etc it all takes extra work and time for such kinds
of oversight.
A Chef solution cannot be so demanding for resources. Heh, maybe Github has
since added some new (relevant) features for Organisation, or they may do
so in the future.
-Cam

On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber cwebber@getchef.com
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, bvessemont@gmail.com bvessemont@gmail.com
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.


#11

I think the proposal is that anyone can post whatever they like in their own namespace. If you want your cookbook to be THE cookbook named “apache2” or “nodejs” cookbook, then you opt-in to a certain governance model or set of standards, and if you don’t meet the standards then the top-level name can be taken away.

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


Daniel DeLeo

On Friday, July 18, 2014 at 11:44 AM, Cameron Cope wrote:

What do you think about making that governance model a requirement for listing cookbooks on the official Supermarket site? It could help reduce confusion in the community if there were a 1:1:1 relationship of supermarket:namespace:government.

-Cam

On Fri, Jul 18, 2014 at 2:34 PM, Adam Jacob <adam@getchef.com (mailto:adam@getchef.com)> wrote:

We’re actively in the process of deciding how we maintain things for Chef proper. Once that is done, I would propose we could look at doing something that basically allows people to “opt-in” to that governance model - where, for example, the author of a community cookbook who intends for it to be “canonical” can choose to adopt the “normal” Chef governance model, and hence have mechanisms for dealing with these cases.

We could then mark cookbooks that have opted in. While it wouldn’t make any statements about quality, it would tell you precisely which ones have a stricter central governance model.

Adam

On Fri, Jul 18, 2014 at 11:22 AM, Cameron Cope <chef@camcope.me (mailto:chef@camcope.me)> wrote:

I’ve heard the statement several times that Chef Software doesn’t want to act like a dictator, but it seems tome that the community wants some sort of leadership and organization. I agree that looking at other examples for namespacing might help, but don’t just look at the technical details of those systems, research how OSS communities organize and govern themselves. I highly recommend looking at governance in Debian, Ubuntu, and the Apache Foundation. As the corporate backer of Chef, I think it’s perfectly reasonable for you guys to decide what your governance model is and how much control your have.

http://oss-watch.ac.uk/resources/governancemodels
https://www.debian.org/devel/constitution
http://www.ubuntu.com/about/about-ubuntu/governance
http://www.apache.org/foundation/how-it-works.html

-Cam

On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber <cwebber@getchef.com (mailto:cwebber@getchef.com)> 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, <bvessemont@gmail.com (mailto:bvessemont@gmail.com)> <bvessemont@gmail.com (mailto:bvessemont@gmail.com)> 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.


#12

I agree - it’s fine if people want to voluntarily agree to a set of best practices and conventions, but the purpose of supermarket is to provide unified access to a pool of content. As soon as people start blessing some cookbooks/content over other content based on adherence to rules, it creates tricky situations for people who don’t want to play ball.

Down the road, too, forcing compliance to governance and policy rules could create a weird set of incentives where whoever is elected/appointed/inherits/rules with an iron fist over Supermarket could leverage their position to manipulate the “blessed” state of given cookbooks.

It seems like it’s better to say that the only governance people have to abide by is the “hit by a bus” or “totally unresponsive maintainer” scenario. If you can get ahold of the maintainer, and they just steadfastly refuse to update/merge the cookbook, you’re free to fork and make your own.

Along the lines of what another email in the thread suggested, I do think that eventually you’ll get to “distributions” or “packs” of cookbooks that have been compiled to be consistent and stable. Someone might even make money by selling updates, support, customizations of specific cookbooks, which is yet another reason to keep Supermarket politically-neutral. It avoids any potential weirdness around penalizing/favoring particular distributions of cookbooks over any others.

Thanks,
Matt


From: Noah Kantrowitz noah@coderanger.net
Sent: Friday, July 18, 2014 2:47 PM
To: Chef Dev
Subject: [chef-dev] Re: Re: Re: Re: Nodejs community CK mess

-Inf, I wouldn’t want Chef Inc having any formal control over governance of my code, nor is my code a democracy, and I would like my stuff to be listed as existing. Supermarket is a sharing site, it should not have strong opinions like this.

–Noah

On Jul 18, 2014, at 11:44 AM, Cameron Cope chef@camcope.me wrote:

What do you think about making that governance model a requirement for listing cookbooks on the official Supermarket site? It could help reduce confusion in the community if there were a 1:1:1 relationship of supermarket:namespace:government.

-Cam

On Fri, Jul 18, 2014 at 2:34 PM, Adam Jacob adam@getchef.com wrote:
We’re actively in the process of deciding how we maintain things for Chef proper. Once that is done, I would propose we could look at doing something that basically allows people to “opt-in” to that governance model - where, for example, the author of a community cookbook who intends for it to be “canonical” can choose to adopt the “normal” Chef governance model, and hence have mechanisms for dealing with these cases.

We could then mark cookbooks that have opted in. While it wouldn’t make any statements about quality, it would tell you precisely which ones have a stricter central governance model.

Adam

On Fri, Jul 18, 2014 at 11:22 AM, Cameron Cope chef@camcope.me wrote:
I’ve heard the statement several times that Chef Software doesn’t want to act like a dictator, but it seems tome that the community wants some sort of leadership and organization. I agree that looking at other examples for namespacing might help, but don’t just look at the technical details of those systems, research how OSS communities organize and govern themselves. I highly recommend looking at governance in Debian, Ubuntu, and the Apache Foundation. As the corporate backer of Chef, I think it’s perfectly reasonable for you guys to decide what your governance model is and how much control your have.

http://oss-watch.ac.uk/resources/governancemodels
https://www.debian.org/devel/constitution
http://www.ubuntu.com/about/about-ubuntu/governance
http://www.apache.org/foundation/how-it-works.html

-Cam

On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber cwebber@getchef.com 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, bvessemont@gmail.com bvessemont@gmail.com 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.


#13

On 7/18/14, 11:59 AM, Sean OMeara wrote:

The relationship between Chef and the Supermarket has always been that
of a programming language to an artifact repository. Chef is to
Supermarket as Java is to Maven, as Ruby is to rubygems, as Python is
to PyPI, as Node is to NPM, etc.
So, its been nearly a year since Adam pointed out that having one apache
cookbook in the universe is a broken model and we still haven’t fully
accepted that the supermarket-to-rubygems analogy is broken.

Rubygems has it baked in that there’s one ‘typhoeus’ gem and one
’berkshelf’ gem, and if you fork things you usually give it a new name
– the Sinatra guys didn’t need to fight with the Rails developers over
the ‘webframework’ gem name.

We have a problem that they don’t. Looking at them for solutions to
this problem is not going to work. Trying to define the problem space
to be identical to Rubygems will just ignore the reality that we have a
problem that they don’t. Looking to them for governance ideas will also
likely not work – and Noah pointing out that PyPI doesn’t really have
any solution to this problem I think is an indication that they don’t
really have this problem in the same way that we do.

The other way around this is that we start giving clever names to all
our cookbooks that have nothing to do with the ‘upstream’ thing that
we’re trying to manage (which i don’t think makes any sense).


#14

On Fri, Jul 18, 2014 at 8:02 PM, Daniel DeLeo dan@kallistec.com wrote:

I think the proposal is that anyone can post whatever they like in their
own namespace. If you want your cookbook to be THE cookbook named “apache2”
or “nodejs” cookbook, then you opt-in to a certain governance model or set
of standards,

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 "ports@freebsd.org", 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).


Daniel DeLeo

On Friday, July 18, 2014 at 11:44 AM, Cameron Cope wrote:

What do you think about making that governance model a requirement for
listing cookbooks on the official Supermarket site? It could help reduce
confusion in the community if there were a 1:1:1 relationship of
supermarket:namespace:government.

-Cam

On Fri, Jul 18, 2014 at 2:34 PM, Adam Jacob <adam@getchef.com (mailto:
adam@getchef.com)> wrote:

We’re actively in the process of deciding how we maintain things for
Chef proper. Once that is done, I would propose we could look at doing
something that basically allows people to “opt-in” to that governance model

  • where, for example, the author of a community cookbook who intends for it
    to be “canonical” can choose to adopt the “normal” Chef governance model,
    and hence have mechanisms for dealing with these cases.

We could then mark cookbooks that have opted in. While it wouldn’t
make any statements about quality, it would tell you precisely which ones
have a stricter central governance model.

Adam

On Fri, Jul 18, 2014 at 11:22 AM, Cameron Cope <chef@camcope.me
(mailto:chef@camcope.me)> wrote:

I’ve heard the statement several times that Chef Software doesn’t
want to act like a dictator, but it seems tome that the community wants
some sort of leadership and organization. I agree that looking at other
examples for namespacing might help, but don’t just look at the technical
details of those systems, research how OSS communities organize and govern
themselves. I highly recommend looking at governance in Debian, Ubuntu, and
the Apache Foundation. As the corporate backer of Chef, I think it’s
perfectly reasonable for you guys to decide what your governance model is
and how much control your have.

http://oss-watch.ac.uk/resources/governancemodels
https://www.debian.org/devel/constitution
http://www.ubuntu.com/about/about-ubuntu/governance
http://www.apache.org/foundation/how-it-works.html

-Cam

On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber <
cwebber@getchef.com (mailto:cwebber@getchef.com)> 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, <bvessemont@gmail.com (mailto:
bvessemont@gmail.com)> <bvessemont@gmail.com (mailto:bvessemont@gmail.com)>
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.


#15

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 "ports@freebsd.org
mailto:ports@freebsd.org", 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).


#16

Hi,

I think it would be really nice to introduce vendor namespace/prefix so
there would be possible to for multiple apach2 cookbooks to co-exists, and
I think that this should be supported not only in the supermarket/berkshelf
but on the chef-client/server level also, so multiple cookbooks for the
same software can co-exists on the same chef server.
there is a nice blogpost explaining why is this a PITA atm:


(probably most of you already read it, but maybe not everybody), and ofc.
anybody can start using prefixes in the cookbook names right now, but
having it officially supported would be better as it would make the format
standardized plus it would make it possible to register your own vendor
name in a central place so it would be less likely/impossible that two
vendor picked the same prefix.

On Fri, Jul 18, 2014 at 11:47 PM, Lamont Granquist lamont@opscode.com
wrote:

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 "ports@freebsd.org
mailto:ports@freebsd.org", 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).


Ferenc Kovács
@Tyr43l - http://tyrael.hu


#17

Hi,

I think it would be really nice to introduce vendor namespace/prefix so
there would be possible to for multiple apach2 cookbooks to co-exists

+1000 to Ferenc’s sentence.

On 19 July 2014 01:24, Ferenc Kovacs tyra3l@gmail.com wrote:

Hi,

I think it would be really nice to introduce vendor namespace/prefix so
there would be possible to for multiple apach2 cookbooks to co-exists, and
I think that this should be supported not only in the supermarket/berkshelf
but on the chef-client/server level also, so multiple cookbooks for the
same software can co-exists on the same chef server.
there is a nice blogpost explaining why is this a PITA atm:
http://www.rallydev.com/community/engineering/chef-dependency-solving
(probably most of you already read it, but maybe not everybody), and ofc.
anybody can start using prefixes in the cookbook names right now, but
having it officially supported would be better as it would make the format
standardized plus it would make it possible to register your own vendor
name in a central place so it would be less likely/impossible that two
vendor picked the same prefix.

On Fri, Jul 18, 2014 at 11:47 PM, Lamont Granquist lamont@opscode.com
wrote:

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 "ports@freebsd.org
mailto:ports@freebsd.org", 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).


Ferenc Kovács
@Tyr43l - http://tyrael.hu

walter dolce | developer
twitter @walterdolce https://twitter.com/WalterDolce
skype walter.dolce
tel +39 (0) 327 597 9830


#18

on retrospect I shouldn’t send emails at 2:30 am, sorry for the typos,
gonna get some sleep. :stuck_out_tongue:

On Sat, Jul 19, 2014 at 2:32 AM, Walter Dolce walterdolce@gmail.com wrote:

Hi,

I think it would be really nice to introduce vendor namespace/prefix so
there would be possible to for multiple apach2 cookbooks to co-exists

+1000 to Ferenc’s sentence.

On 19 July 2014 01:24, Ferenc Kovacs tyra3l@gmail.com wrote:

Hi,

I think it would be really nice to introduce vendor namespace/prefix so
there would be possible to for multiple apach2 cookbooks to co-exists, and
I think that this should be supported not only in the supermarket/berkshelf
but on the chef-client/server level also, so multiple cookbooks for the
same software can co-exists on the same chef server.
there is a nice blogpost explaining why is this a PITA atm:
http://www.rallydev.com/community/engineering/chef-dependency-solving
(probably most of you already read it, but maybe not everybody), and ofc.
anybody can start using prefixes in the cookbook names right now, but
having it officially supported would be better as it would make the format
standardized plus it would make it possible to register your own vendor
name in a central place so it would be less likely/impossible that two
vendor picked the same prefix.

On Fri, Jul 18, 2014 at 11:47 PM, Lamont Granquist lamont@opscode.com
wrote:

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 "ports@freebsd.org
mailto:ports@freebsd.org", 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).


Ferenc Kovács
@Tyr43l - http://tyrael.hu

walter dolce | developer
twitter @walterdolce https://twitter.com/WalterDolce
skype walter.dolce
tel +39 (0) 327 597 9830


Ferenc Kovács
@Tyr43l - http://tyrael.hu


#19

On Friday, July 18, 2014 at 5:24 PM, Ferenc Kovacs wrote:

Hi,

I think it would be really nice to introduce vendor namespace/prefix so there would be possible to for multiple apach2 cookbooks to co-exists, and I think that this should be supported not only in the supermarket/berkshelf but on the chef-client/server level also, so multiple cookbooks for the same software can co-exists on the same chef server.
there is a nice blogpost explaining why is this a PITA atm: http://www.rallydev.com/community/engineering/chef-dependency-solving (probably most of you already read it, but maybe not everybody), and ofc. anybody can start using prefixes in the cookbook names right now, but having it officially supported would be better as it would make the format standardized plus it would make it possible to register your own vendor name in a central place so it would be less likely/impossible that two vendor picked the same prefix.

Have a look at this RFC, it would solve this problem (and generally make all the things in the blog post you linked a lot better) https://github.com/opscode/chef-rfc/pull/20


Daniel DeLeo


#20

On Fri, Jul 18, 2014 at 9:28 PM, Lamont Granquist lamont@opscode.com
wrote:

Noah pointing out that PyPI doesn’t really have any solution to this
problem I think is an indication that they don’t really have this problem
in the same way that we do.

As an example of same problem on pypi, there is “netifaces” package:
First there was a “netifaces” package (linked hosted on a private server).
His maintainer doesn’t accept any patch, so someone create "netifaces-py3"
for python3 compatibility. But this one does’t answer to any new PR, so
someone create a “netifaces-merged” to merge py3 + fixes.

About namespace, it’s really important to have a “main” namespace. It’s a
real difference over puppet and lead to a better quality of community repo.
Moreover, with berkshelf you can use your own cookbook from git really
easily and lead to a “private” namespace.

In my opinion, debian / ubuntu / … repo are the “old way”. You don’t
trust upstream and do your best yourself to manage dependencies problems.
pypi / rubygems / … are more like “do what you want”. Democracy + PR will
lead to a working system. And it works!.. with some help of “environment”
(bundler / virtualenv).

In chef case, berkshelf + dependencies is our response to “environment”,
but we can do more. jenkins-ci plugin repository is a good example:
any upstream people can push a plugin, but sources are stored in a
"jenkins-ci" repo with policy and CI integration. You don’t have a
"myRepo®" conservative behavior (for public publicity) who can block many
maintainers to give ownership (true story).
In jenkins-ci, governance is really simple:
https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document#GovernanceDocument-Helpingandtakingoverdormantplugins
Mailing-list is community (but we can do better tools).

Maintainers can accept less “rights” on their cookbooks if we give us tools
to help them: CI integration with TK…
Of course, some will twittFlame but there are not obliged to use
supermarket to use Chef itself (and they can hosted there own with their
own rules).