On Sun, Oct 02, 2005 at 12:04:55PM +0200, Mark Wielaard wrote: > If you are looking for some guidelines for working together on code and > how to keep track of who wrote what when then I would recommend starting > out with our GNU Classpath Hacker Guide. Specifically chapter 7. > "Working on the code, Working with others". It explains that the main > rule is to always explain and discuss everything on the patches > mailinglists. No commit is made before it has been posted first. > http://www.gnu.org/software/classpath/docs/hacking.html#SEC8
Cool! I also like http://subversion.tigris.org/hacking.html which is basically the same kind of guide, only a little different in some corners. At apache, lots of projects have subtly (or not so subtly) different ways of doing things, for example HTTPD has this: http://httpd.apache.org/dev/guidelines.html whereas for example Apache Gump sometimes sees a rather sizeable codebase overhaul without prior discussion. Both are fun and healthy projects, and both do things the "apache way". Just differently ;) In particular, I like to believe that the "lazy consensus" concept around the ASF is nice -- it means that, sometimes, if you're relatively confident that everyone agrees with the changes you're about to make, you just make the change, and then when the commit notification scrolls by, if it turns out someone didn't agree, they reply, and explain why not, and you back out the change. Eg "commit then review", so you do commit stuff before posting it to the mailing list. But only when confident that the change is "non-controversial". And then we try and err on the safe side. We'll see how it goes. LSD
