Thanks mark for this link. This captures a lot about how I like to
work. Some key things :
"The main thing is to always discuss what you are up to on the
mailinglist. Making sure that everybody knows who is working on what
is the most important thing to make sure we cooperate most
effectively." (aka "Don't be a cowboy" :)
We also have the 'adding anything non-trivial that you didn't write
yourself' pretty well covered with our bulk contribution policy.
We will certainly steal this :
"Commits for completely unrelated changes they should be committed
separately"
as it's good to remind people of this.
And will emphasize maintaining the changelog. One solution to that
is to let JIRA generate your change list, but that presumes that any
work people do is logged in a JIRA. I think JIRA is a great tool,
but I also hope to avoid people having technical discussion in JIRA
comments, which sometimes happens...
More inline :
On Oct 2, 2005, at 6:04 AM, Mark Wielaard wrote:
Hi,
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
Just following that main rule makes sure that everybody knows what and
why things happen.
I think that for now, going with commit then review removes synch
points that we should be getting anyway with community monitoring of
the svn diff stream in email. I know that has worked very well,
allowing people to work (with "always discuss what you are up to" as
a prereq) and having the patch discussed only if someone throws an
exception. That said, I do believe that with big patches, or tricky
things, it's best that the author discuss first, but this seems to be
"you know it when you see it".
Next there are all kinds of practical guidelines such
as maintaining a clear and concise ChangeLog for every commit.
Splitting
commits for unrelated code changes, or changes to code and changes to
formatting, etc for clarity. And when to ask for permission to
commit a
change. Also important is to always use the same code style guide (see
chapter 6) so that the code looks like it is part of a whole.
Agreed.
There is currently no strict rule about "author tags". Some people add
them some don't. This isn't really a problem. The ChangeLog file
documents in very precise detail who really wrote what (and of course
CVS has a similar record if you happen to be online). And there is a
AUTHORS file listing all active hackers and a THANKS file for
documenting who else helped out with bug reports, hints or moral
support. Also the release announcements always include a full list of
all contributors and a summary of their contributions.
Currently there are about 80 committers creating around 15 patches a
day. And the Hacker Guide really helps to keep some structure to the
project without being so strict that it makes contributing difficult.
The key is to keep the rails greased and remove roadblocks to
everyday work... That's why (this point anyway) I'm so in favor of
commit then [lazily] review.
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
