river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: new site added to SVN and published
Date Wed, 03 Jan 2007 15:28:56 GMT
Geir Magnusson Jr. wrote:

>> I disagree. For cheiron.org I do most of the work myself, but
>> nevertheless anything substantial is going through JIRA if it was only
>> to keep track of things done for the release notes. Especially when you
>> already have a stable codebase gradually improving and getting
>> bug-fixed. But I admit with complete new projects I tend to be less
>> bureaucratic.
> 
> 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
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
list (no seperate list for generated artifacts) so other interested
people can see whether they think the issue is relevant or not.

When I start working on it, JIRA sends a message to the dev list so
people know I'm about the start coding. After I check in my code
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
waits a while with resolving the issue.

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
and committed by one of the committers the issue can be resolved.

I realize this won't work exactly the same way as for the projects I'm
working on, but still hope to see maybe a somewhat more formal way of
working or at least for some parts of the project.

> 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 :-)
and I admit I'm an infant with SVN (Perforce addict) but wouldn't a
report generated by SVN contain a lot of clutter in that case. Also for
release notes I really like the issue description instead of the
comments people in general use for their commit.

If I recall correctly the Jini team didn't write a single character
before there was an issue in their tracking system. I adopted this style
and found it worth while on a rather stable codebase. I'm curious to
know what the others think of this.

And maybe I'm completely out of bounds here but I think that even some
form of issue planning (in what version to expect what) can be
beneficial as well, JIRA is great for that too.

>>> 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...)
>>
>> 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
>> digging them from my email archive.
> 
> 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
issue neatly in JIRA. But as I've not that much experience with working
in an ASF style project opposed to playing a dictator I really don't
know what will work the best.
-- 
Mark

Mime
View raw message