- From: Jens Meggers <jens.meggers@firepad.com>
- Date: Thu, 29 Mar 2001 10:20:20 -0800
- To: "'jose.kahan@w3.org'" <jose.kahan@w3.org>, www-lib@w3.org
looks great! I'm happy to help out. Jens -----Original Message----- From: Jose Kahan [mailto:jose.kahan@w3.org] Sent: Donnerstag, 29. März 2001 02:13 To: www-lib@w3.org Subject: Proposal: fast track procedure for accepting patches As you know, today I'm the only one commiting patches to the CVS base. It sometimes takes time because either I'm busy with other tasks and I like to check each patch to see if it doesn't break something else and if it's ok... and even edit it to look more a la libwww present style. My motivation is to make sure that the patch is generic enough to work with all the applications, and not just the one the contributor is presently using. But the problem is that patches keep accumulating. My proposal to make this work faster: - Simple patches (typo corrections and things that don't move too much the internals) should be commited whenever possible. - I'll commit complex patches if they have been tested by someone else than the patch contributor. Ideally, the more tests we have, the safer the patch can be. In addition, the patch contributor should agree to be available (answer e-mail) in case someone discovers a problem. - Open the access so that other people can help doing the commits. In particular, I'm thinking about Jens. - I can make another mailing list where every CVS commit can be tracked. I hope this can help avoid having multiple copies of libwww and making it go forward whenever I'm busy with other tasks. How does it look like? Even if a patch breaks something, it's not so bad provided we can react quickly and fix it. -jose
Received on Thursday, 29 March 2001 13:31:01 UTC