Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Wed, 3 Sep 2003 23:26:10 +0100
Subject: Re: Closing items 49-56,58-65 as duplicate -- PLEASE READ
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Alex Blewitt <Alex.Blewitt@ioshq.com>
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <20030903165831.A29419@sweetums.ce1.client2.attbi.com>
Message-Id: <9EB18EDA-DE5D-11D7-93B6-0003934D3EA4@ioshq.com>

On Wednesday, Sep 3, 2003, at 17:58 Europe/London, David Blevins wrote:

> On Tue, Sep 02, 2003 at 11:06:59PM -0700, Brian Behlendorf wrote:
>>
>> If you want an opinion from someone to the side, it's seems quite
>> preferable to have separate issues remain separate and open, even if 
>> they
>> are all very related, until each is closed.  Doesn't strike me that
>> closing all these issues as duplicates was a good idea.
>>
>> 	Brian
>
> I agree totally, but I don't think bug tracking is the real issue here.

The bug tracking system is perfectly capable of handling many bugs, and 
indeed they may be related. This is why the bug-tracking system has 
dependency information.

> There have been a few very critical emails on this incident.  I have 
> compiled a list of the changes so that everyone may understand why 
> they were grouped.  Please note the times.

There have, from what I can see, been a similar number of e-mails both 
being critical for, and critical against.

> TIME    NO   DESC
>  5:45   49 - Misspelled a word
>  6:03   50 - Added a parameter to a method
>  7:17   51 - Changed a signature from public to private
>  8:05   52 - Same change as 51, plus additional changes
>  8:11   53 - Changed a signature from public to private (updates 52)

These were in response to Davanum Srinivas' mail that pointed out 
discrepancies between the JavaMail specification and were individual 
bugs in themselves. They should have been tracked separately, and were 
therefore filed as such.

>  9:45   54 - More complete patches to javax.mail
>  9:48   55 - Added a toString method (3 lines of code)
>  9:50   56 - Revision to a javax.mail class, added test case
> 10:08   58 - Revision to a javax.mail.internet class, added test case
> 10:10   59 - Revision to a javax.mail.internet class, added test case
> 10:12   60 - Revision to a javax.mail.internet class, added test case
> 10:15   61 - Revision to a javax.mail.internet class, added test case
> 10:19   62 - Revision to a javax.mail.internet class, added test case
> 10:23   63 - Revision to a javax.mail.internet class, added test case
> 10:27   64 - Revisions javax.mail.event package
> 10:32   65 - Revision to a javax.mail.internet class, added test case

These were changes to varying classes, and providing new test cases in 
all. They could have been factored into one patch (or a small number of 
them) as I have already agreed.

> 16 total in a span of 5 hours, all to packages only Alex is working on.

And it was I who filed the bugs, mostly due to work that I did over the 
weekend when not connected.

Time of filing bug != time of working on bug.

> I am very happy to review changes and assist contributors, but I do 
> not encourage people to send a steady stream of patches all day long 
> because they are upset they don't have cvs privileges and are trying 
> to make a point.

I was not, in fact, trying to make a point. I was trying to provide 
sufficient detail so that instead of dumping a whole lot of changes in 
a single splat, I categorised what I had done in each one so that it 
was possible for more fine-detail commits (and therefore, commit 
messages) could be applied to the repository in the way in which I am 
accustomed to doing. It was better to play safe than sorry, and err on 
the side of too many than too few. In that way, the committer could 
decide what the appropriate action was, and group them where necessary.

It is unfortunate that this was interpreted as a measure of upset; in 
fact, it was more upsetting to see the response rather than a cause for 
submitting many patches. It is clear that the JIRA bug tracking system 
is capable of handling many bugs with relationships between them, and 
whilst I acknowledged there were many bugs filed and that there could 
have been fewer, it was easily a situation that could have been 
clarified instead of vented in public. Indeed, I tried to do so but had 
no response.

I am all for learning about other reasons/opinions/thoughts on how to 
do things better. Next time I have a set of changes, I will file them 
as a single non-atomic large patch as required by over-worked 
committers.

As for commiter status; I think the point has already been made that a 
meritocracy is based on two key points; the ability to code, and the 
ability to fit in with development philosophy. I am of the opinion that 
my contributions to the JavaMail packages satisfy the first, and that 
the discussions in which I have partaken on this discussion list show 
that I am very much someone who is interested in new ideas and new ways 
of doing things. Unfortunately, this does not necessarily mean that I 
also fit in with how the project has been started, nor 'in' with the 
initial development team, which is why I am where I am at the moment.

Unfortunately, my personal voyage of this experience has gone form 
actively interested person, through mildly disinterested, to downright 
disheartend about my input into the project. I feel this is a great 
shame for both me personally and what I could have contributed to the 
group in the future.

Alex.