harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [project policy] Author credit and attribution
Date Sun, 02 Oct 2005 12:50:54 GMT
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  

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.


> 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 Magnusson Jr                                  +1-203-665-6437

View raw message