Here's my take: On Wed, 2007-04-25 at 18:57 -0500, Tomas Restrepo wrote: > 1- When can we start actually making commits to the qpid tree? When you've written some code worth committing :)
> 2- Do we have any rules or conventions in place for commits? (i.e. commit > message format and so on). Anything we need to be aware of to avoid screwing > things up? The golden rule is: no tests failing after your commit. For C++ http://cwiki.apache.org/qpid/qpid-c-documentation.html has some guidelines, likewise for Java though I'm not as familiar. > 3- Like many others, I'd start working on the M2 branch, but we need to keep > the trunk in sync as well. Could someone offer any suggestions on what the > best way to do this would be? Is it better to do so by hand, using svnmerge > or what? If the latter, can anyone offer any suggestions as to how to use > it? (I've seen http://www.orcaware.com/svn/wiki/Svnmerge.py of course). svnmerge.py is the way to go. Rupert answered this one in another mail. Note that with svnmerge you can also block merges that should not be done. > 4- Once I'm ready to start doing my own commits, I'd thought I'd start with > the JIRA's for which I've already submitted patches and that are pending. > These are: > QPID-435: Fix for Headers Exchange test > QPID-441: Fix handling of bounced messages > QPID-398: SSL Support for .NET Client > > Does that sound OK? Sounds like an excellent way to get started. > BTW, one final question: Who is supposed to close an issue in JIRA? IMO the person who commits the change (for themselves or on behalf of a non-committer) should close the JIRA, that's what I do. Ideally they should have already assigned the JIRA to themselves. > At least > on the .NET client side, they seem to remain open forever, even when patches > have been proposed and even committed already into the trunk... In that case either hound the person who resolved the problem to close the JIRA or just close it yourself if you're certain its been resolved. Cheers, Alan.
