geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: Closing items 49-56,58-65 as duplicate
Date Mon, 01 Sep 2003 18:50:52 GMT
On Monday, Sep 1, 2003, at 14:08 Europe/London, David Blevins wrote:

> You've opened 16 separate Jira items in the last few hours, each with 
> several updates.  I have assigned those items (49-56,58-65) to me, 
> marked them as duplicate, and closed them.  I have opened a new item 
> (66) titled "JavaMail Improvements" and also assigned it to me.
>
>    http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-66
>
> When you are done for the day, please create exactly one patch file in 
> diff formate for all your changes and attach it to that item.

For the record, it is not possible to create cvs diffs with new files 
attached when that person does not have write access to the CVS 
repository. Doing so (-u -N) results in a CVS error 'No file in 
repository'. As such, individual test cases were attached as files 
whilst the corresponding code was supplied as patches. Thus it is not 
possible in all case to supply solely a patch in patch format.

It should also be noted that a variety of the bugs that were submitted 
are not just JavaMail improvements; rather, they were one of (a) 
necessary changes to bring it in line to the space, (b) implementation 
of existing classes, and (c) a supplied modification of the JAF classes 
necessary to begin testing worth with the JavaMail classes.

Lastly, some of the bugs are dependent on prior bugs being implemented; 
they were therefore filed as separate bugs so that the ones that could 
be fixed now could go straight in, whilst the dependent ones were kept 
back until such time they could be fixed.

Additionally, I am working on code that does not yet compile or pass 
any tests, and I wanted to explicitly ensure that this code was not 
absorbed into any daily update of patches that I sent, hence working 
through all of the changes individually was the best way of ensuring 
that necessary dependencies and correct code was checked in.

It would be trivial for me to generate a patch of the entire JavaMail 
directory and attach that as a patch, but such bulk changes do not 
benefit from being in a single large patch with 'wrote JavaMail code'. 
Thus marking them as separate was significantly more work to ensure 
that they could be applied individually where necessary/possible.

> As a reminder, one of the criteria for becoming a committer is 
> demonstrating good ability to work with others.  Please help me help 
> you by using the patch tracker responsibly.

Indeed. And IMHO the correct use of the patch tracker is to use the 
'link issue' feature that JIRA provides to show dependencies between 
bugs (c.f. 
http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-64 ) which 
is then lost in an uber-bug.

By all means create such an uber-bug to relate the items together, but 
keep the minor bugs open and relate them using the 'link issue'. Then 
you can arrange for a list of them to be viewable by one bug, and keep 
track of which ones are applied and which ones aren't solved yet. Then, 
when all related items are solved, you can close the uber-bug. Marking 
them as duplicates is a misues of the bug tracker.

Alex.


Mime
View raw message