Hi, On Thu, Feb 03, 2005 at 23:46:38 +0100, Simone Rota wrote:
Hi,
since I'm committed to annoy all the people on this list, I remind there's a useful CLC Wiki page proposal by sten here:
http://clc.morpheus.net:6999/clc/tktview?tn=38 Yeah, I'm sorry this had to wait for so long.
Extract: ### - If any download is broken; feel free to fix it. One should then courteously notify the maintainer of the port. that's fine with me (just: no changes for "temporary down" servers; no changes for "slow servers").
- For all other fixes, email a patch to the maintainer. ... and maybe clc-devel as well? I mean, it might be that the maintainer is not around, in which case it would make sense to apply the patch if there's a consensus in clc-devel.
- If the fix is security-related, and the maintainer does not respond after 48 hours, commit and tag. As Daniel suggests, security related patches should go in really fast; maybe also with a short stop in clc-devel? Just to avoid that a security aware person with no knowledge of port X applies a patch since it appeared in any mailing list or other distro.
Maybe we could set the port revision field to 'hotfix' and make the maintainer review the changes, and he would change it then to 'revision=1'; this way, the changes would go out really fast, while it would be obvious that this port need a review by the original maintainer.
###
Just my 2c: - If there's a security update _AND_ a maintainer know what he's doing, I'd prefer an immediate update when available instead of waiting 2 days with an unpatched system. That could go just for remote vulns or in general. I agree with that, it's just that it's hard to know whether you know what you're doing, therefore the suggestion of sending it to clc-devel before rushing into something.
- I feel very small changes could be handled by a clc member that is not the maintainer, ie when the minor version for a port changes and there are no consequences on related ports (or no related port at all). No related ports is fine; seeing all consequences might be hard sometimes, therefore again I'd prefer a review step.
So, If anybody would like to share his point of view, feel free to reply to this thread Thanks for bringing this up! I think we'll have to work a bit on our communication skills, to avoid that good suggestions are forgotten or lost.
Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net