[clc-devel] The question of maintainer protocol

Johannes Winkelmann jw at tks6.net
Fri Nov 19 07:56:14 UTC 2004

On Thu, Nov 18, 2004 at 23:09:14 -0700, Nick Steeves wrote:
> Hi,
> Recently I've had quite a time trying to figure out how a CLC member should 
> submit fixes to another maintainer.  Documentation on CLC's CVS conduct is 
> conspicuously missing.  We should write, or reference a document of 
> procedural guidelines.  I would appreciate if everyone would comment on 
> Ticket #38.
I guess we might require some guidelines like this if we decide to allow
many more maintainers. I'm a bit surprised that we need them already
now, since it would only define how two persons talk together,
which doesn't need a big protocol IMHO. Given that we try to recruit
"team players" according to the maintainer guidelines, I don't think
it's too much asked if we require new maintainers to be able to
communicate, especially given that "communicate" is another requirement
on the list (maintainer guidelines).

What might be of use are rules which are centered around ports, not
people, like:
- if a download is broken (as in fam), commit and tag
  REASON: there's no point in keeping a broken port
  ACTION: notify the original poster
  NOTE:   have a look at the port; if you're not confident that it works
          the same as before, try to get the original patch and
          add it to the CVS itself
- if it's a security or otherwise critical fix, send a patch to the
  maintainer with an URL to the report. If the maintainer doesn't
  respond in 2 days, commit and tag
  ACTION: notify the original poster
  NOTE:   if you're uncertain about the fix, contact clc-devel first
- if you have change suggestions, contact the maintainer with a
  description of your changes. If he doesn't respond, resend to
  clc-devel to discuss it there and apply if it seems to make sense.

Would this be enough for now?

Kind regards, Johannes
Johannes Winkelmann              mailto:jw at tks6.net
Bern, Switzerland                http://jw.tks6.net

More information about the crux-devel mailing list