[clc-devel] The question of maintainer protocol
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. Thanks, Nick
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@tks6.net Bern, Switzerland http://jw.tks6.net
Hi, Yes, this is exactly what I was looking for. Thank you for replying. One other case I've been wondering about: What if updating own port a, which depends on someone else's port b, cannot build without an update to b? Currently, I fork a httpup version to publish along side updated port a, while contrib's a remains old. Perhaps we could put these guidelines into the Wiki? \/ \/ \/ On November 19, 2004 12:56, Johannes Winkelmann wrote:
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.
Cheers, Nick
On Fri, 2004-11-19 at 01:50 -0700, Nick Steeves wrote:
Hi,
Yes, this is exactly what I was looking for. Thank you for replying. One other case I've been wondering about: What if updating own port a, which depends on someone else's port b, cannot build without an update to b? Currently, I fork a httpup version to publish along side updated port a, while contrib's a remains old.
To answer the first, I have generally emailed the maintainer in the past. If a port is unmaintained, I don't feel bad about updating it myself, but if it's got an active maintainer listed, I mail said maintainer an update. As for the second, I also fork an httpup version of it and then follow the first bit. :) Matt (jaeger@freenode/#crux)
Thank you Johannes for the very useful email Nov 19. I've re-worded the ticket #38 to accordingly. Does it look ready to integrate into the Wiki? Should it warrant it's own document, or should it be appended to the official Maintainer Guidelines? http://clc.morpheus.net:6999/clc/tktview?tn=38,7 -- Nick
participants (3)
-
Johannes Winkelmann -
Matt Housh -
Nick Steeves