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: How to get rid of bugs, the easy way.
Date Mon, 01 Sep 2003 18:19:35 GMT
On Monday, Sep 1, 2003, at 18:22 Europe/London, Aaron Mulder wrote:

> I suspect that one person is going to handle all these bugs
> together, rather than 10 different committers each taking one of the 
> bugs
> and considering it in isolation.

JIRA and other bug tracking tools allow bugs to be assigned to the same 
person and performed in a single go, without the bug-tracking system 
needing to have an extra bug that loses information. For example, one 
of the bugs is actually dependent on another bug that is currently 
assigned to someone else and will fail to compile before that bug is 
processed.

Naturally, the original bug report included this information. The 
uber-bug did not.

> Is there a reason you didn't submit all
> the bugs as one big bug/patch to begin with?  Perhaps you thought some 
> of
> the changes were debatable and you wanted separate consideration for 
> each?
> Perhaps you came up with them all at different times?  But it looked 
> from
> the description like they were all trivial changes, and you submitted 
> them
> all within 5 minutes.  I wouldn't have thought every misspelling needed
> its own separate bug.  If you wanted to ensure nothing was missed, you
> could have submited a single patch file for all the changes.  Am I 
> missing
> something?

I am working on implementing the rest of the JavaMail API, and as such 
there is a lot of code in there that doesn't quite work yet that it was 
necessary to extract the stuff that I had done from the stuff that I 
hadn't.

Additionally, to perform increments against a code-base with a 
reasonable level of detail requires more than just a collection of 
random bugs linked into one. The patches filed were not spelling 
changes -- there was only one spelling change in the suite of bugs 
filed. The rest of the bugs were implementation of code that was done 
over the weekend, with unit tests to be able to check the correctness 
of them. Thus they were separate bugs because they addressed several 
problems.

I submitted them in 5 minutes because I had a weekend's worth of code 
to file and this was my first available opportunity to do so.

Lastly, you will note that it is not possible to submit new files via 
the cvs diff -u -N command when you do not have write access to the 
repository, and since a number of new test cases were created as well 
then it was not possible to submit them with a patch. Instead, I paired 
up patches of work that I had done with the new test cases and 
integrated them in each bug.

> Finally, the tone of your message seemed a little excessive.

No more or less than I intended. A bug tracking system such as JIRA is 
perfectly capable of (a) having multiple bugs filed against one person 
(whether they work on them independently or at the same time), and (b) 
having a relationship set up so that if necessary, an uber-bug can be 
created that depends on all the little bugs being correctly filed. 
Closing the bugs, and especially failing to link them together with an 
uber-bug is actually a gross misuse of a bug-tracking system.

I tried to contact the closer of the bugs to resolve the problem, but 
to no avail. I therefore wished to make the public appeal to the 
maintainer of the JIRA bug database to resolve the issue.

Here are just a sample of reasons why closing bugs duplicates is a bad 
thing:

o Loss of dependencies (whilst there were bugs dependent on others 
being fixed, these have now disappeared)
o Loss of tracking (it is not possible to ensure that all bugs are 
fixed properly)
o Loss of notes specific to each bug
o Loss of patches supplied
o Loss of new code submitted as files (along with directory 
information) supplied

So we are now in a state where the uber-bug may be closed without 
application of some/any of the original bugs being fixed.

Alex.


Mime
View raw message