Re: new site added to SVN and published

[Craig L Russell]

On Jan 3, 2007, at 9:25 AM, Geir Magnusson Jr. wrote:

On Jan 3, 2007, at 10:28 AM, Mark Brouwer wrote:

Geir Magnusson Jr. wrote:

I disagree. For cheiron.org I do most of the work myself, but

already have a stable codebase gradually improving and getting
bug-fixed. But I admit with complete new projects I tend to be less
bureaucratic.

nevertheless anything substantial is going through JIRA if it was only to keep track of things done for the release notes. Especially when you

Do you mean

a) you make all the changes, make a patch, submit it to JIRA, download the patch, apply the patch to a fresh tree, and then commit

Not exactly. I work either on the main codeline or in some version

list (no seperate list for generated artifacts) so other interested
people can see whether they think the issue is relevant or not.

branch, but not before there is an JIRA issue created for the task, bug or improvement at hand. The JIRA issue is sent to the developer mailing

I see

When I start working on it, JIRA sends a message to the dev list so
people know I'm about to start coding.

JIRA is nice in that any change of status of an issue gets sent to the distribution. It's a matter of discipline that committers actually use JIRA to "start an issue" so the notices get sent.

After I check in my code

waits a while with resolving the issue.

directly into the repository I resolve the issue which leads to a post from JIRA to the dev list. In case of commit before review I suggest one

Both JIRA and svn will generate notices to the rest of the team.

and committed by one of the committers the issue can be resolved.

No patches are submitted to JIRA, for those that have no commit rights I also think that sending the patch to the dev list is the best thing to do. No need to attach that one to the isse. When the patch is accepted

That's one thing you may want to modify - ask that patches are posted to the JIRA, as it requires the submitter to explicitly acknowledge that the stuff is contributed under the terms of the Apache License. Keeps any questions about what's a contribution to a minimum...

This is a very important part of the Apache Way. Contributors really should sign CLAs which legally binds contributions. The tick box on JIRA attachments also reminds folks that the patch is in fact a contribution.

working on, but still hope to see maybe a somewhat more formal way of
working or at least for some parts of the project.

I realize this won't work exactly the same way as for the projects I'm

It's up to you guys.

b) note changes in JIRA afterwards

Or during the process of receiving patches, discussing and committing them.

c) something else?

I think b) is fine, if you are simply looking for a change tracking tool, although if you build a decent commit message discipline into the community, you can also just ask SVN what changed between releases... and that should be far more accurate.

Often it requires multiple changes to the code for the same issue before everybody is happy (I think/hope this will be a very picky community :-)

JIRA works well for this case as well. I like to have code uploaded to JIRA instead of scouring emails for patches. JIRA allows you to replace a patch with "the latest" code in progress, and it's easy for reviewers to apply the patch and comment, iterating on the proposed fix before svn commit.

and I admit I'm an infant with SVN (Perforce addict) but wouldn't a

release notes I really like the issue description instead of the
comments people in general use for their commit.

report generated by SVN contain a lot of clutter in that case. Also for

I agree. Once an issue has been beaten to death on JIRA, the commit message can be relatively brief. commit -m "RIVER-123 added snarfgargle to mediation requests" src/java

If I recall correctly the Jini team didn't write a single character

and found it worth while on a rather stable codebase. I'm curious to
know what the others think of this.

before there was an issue in their tracking system. I adopted this style

I like this approach as well. I've seen both discuss on the dev alias and discuss on the JIRA issue work well, so this is a matter for the team to work on. It might not even be necessary to formalize where the discussion takes place. Some people like having it all on the JIRA issue; some prefer to follow threaded discussions on aliases. But basically having a JIRA to track all code changes is a statement of formality that should be agreed by the community.

form of issue planning (in what version to expect what) can be
beneficial as well, JIRA is great for that too.

And maybe I'm completely out of bounds here but I think that even some

Yep. It is. But be careful to keep things as open and welcoming to volunteers. Rigid process is off-putting to some people.

JIRA is great for tracking, but there are things to be cautious of - I've experienced technical discussion moving into the JIRA itself, which I think is not good, because it loses the bigger audience (IMO). I hate having to read JIRA discussions on the JIRA-generated emails, and it makes it hard to participate offline (unlike email) or search (unlike email...)

digging them from my email archive.

I'm aware of that but in case of tasks to be implemented somewhere in the future I like to see any conclusions of discussion in JIRA versus

That's fine - that's a good use of JIRA. But you can simply just put a URL to the mail archive in the JIRA... easy to find later.

That is possible, but I'm inclined to describe the summary of such an

in an ASF style project opposed to playing a dictator I really don't
know what will work the best.

issue neatly in JIRA. But as I've not that much experience with working

Craig

Well, this should be interesting. There are a wide range of working styles in Apache projects that depends a lot on the community who are actively working on the project. It might be good to propose some of the guidelines as updates to the site and see what people think. That way, it's not just talk; it's proposed action.

--
Mark

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature