geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: Closing items 49-56,58-65 as duplicate
Date Mon, 01 Sep 2003 22:23:14 GMT
On Monday, Sep 1, 2003, at 21:56 Europe/London, Jason Dillon wrote:

> I do not think the policy of one patch per day is realistic, but the 
> 16 Alex added was out of hand IMO.

I agree that there were a lot -- and I would have preferred to submit 
less. However, there were several different categories of bugs; in 
particular, glitches introduced in the specs signatures which I thought 
were important enough to be raised as individual bugs.

Then there were implementation issues over code that I've written over 
the weekend, and the test cases that went with them. These could have 
been joined into one/fewer bugs, but I have always thought it better to 
give the option of committing smaller changes into a CVS server with 
appropriate small logs. Normally, if I were committing to a CVS 
repository directly I'd have done lots of small changes rather than one 
big commit, because then the changes/logs would be more atomic.

On Monday, Sep 1, 2003, at 21:50 Europe/London, Aaron Mulder wrote:

> Please let's try to remember that the people we're dealing with
> here are intelligent adults.  Mocking and exaggeration are probably
> unlikely to change anyone's mind.

This is true, but the two positions (1 vs 16) are opposing extremes. 
The correct answer obviously lies somewhere between.

> No one is saying that every developer must submit precisely one
> patch per day, regardless of the code in question.  However, it struck 
> me
> as unreasonable that 15+ patches were submitted in the space of a few
> minutes, all for the same area of the code, when only one person was
> working on that area of the code, and all the patches would likely be
> handled by the same committer.

The patches were sent in minutes because that was the first time I was 
connected since Friday afternoon. As such, I had a number of changes to 
make to be sent up in as a committer. I thought it was equally 
unreasonable to send 150k of patches (which is actually the amount I 
generated from the two sets of packages I have been working on over the 
weekend. I would have been unsuprised to have a patch of that magnitude 
turned down on the grounds of not being atomic anough.

> Compare one big patch to 15 little patches.  It's harder to sort
> through all the little patches and determine how they relate.  It's 
> harder
> to apply them in the correct order.

Absolutely not. All the bugs were filed with the correct relationships 
to other patches, and all filed bugs had corresponding 
code-and-unit-tests with them as well. They could have been applied in 
any order with the comments as made in the bugs, whilst respecting 
dependent bugs.

> It's harder to make sure they all get applied.

100% disagree. A separate bug that is open indicates that it has not 
been applied. If it is closed, then it has been applied. Merging them 
into one bug is much harder to make sure they all get applied.

> It's harder to figure out which ones obsolete which other ones.

All the patches were submitted in order to ensure that obsoletion does 
not occur. Indeed, it is more likely that a big patch would then have 
obsoleted patches applied afterwards.

Case in point; in one of the patches I didn't change all occurrences of 
RuntimeException. I wanted to apply a subsequent (that is, obsoleting 
patch) to the original bug report, but I couldn't since that bug has 
been closed (incorrectly) as a duplicate. Instead, I had to add it to 
the UberBug instead.

> And remember, this is all on the same area of the code, which is 
> otherwise
> untouched.  None of this is to say "impossible", but developers, as we 
> all
> know, are lazy.

Yes, indeed we are. And it would have been incredibly easy/lazy of me 
to say 'Here's 150k of what I've been doing over the weekend, please 
dump this into CVS'. Instead, I categorised it into the different areas 
that I did which was significantly more work for me, and also for the 
person who would end up committing them.

The main problem is that I am working on developing a whole new set of 
code, and I have to submit the files as patches instead of the atomic 
nature of CVS commits that I do when working with a (writable) 
repository. Whilst patching works well for submitting small changes, it 
tends to break down when larger and larger amounts of work are 
submitted and still need a relatively respectable level of commits 
instead of huge chunks.

> Now, the author has pointed out that some of the files were new,
> and cannot easily be incorporated into a patch file.  As well, the 
> author
> needed to select several specific changes to submit, while leaving
> numerous others alone.  I don't think these are incompatible with 
> sending
> one big patch -- cvs diff takes a list of file names or directories to
> operate on, and new files can be zipped separately, resulting in one 
> patch
> file and one zip file.  This makes it instantly clear what is supposed 
> to
> be applied together.

Yes, I could have done this. I could have integrated more changes into 
each patch than I did. I'll also agree that there were a lot of small 
bugs filed. I still think that there would have been many rather than 
few patches, in particular to (individually) deal with the issues 
raised by Davanum Srinivas earlier today.

However, I do not have a script for finding out what files are new and 
what files are changed, nor the levels of changes that I had made. So 
instead I played it safe and selected those ones that I knew I had been 
working on and submitted them in conjunction with their test cases.

> It is trickier to apply patches to patches or patches that
> obsolete patches in this scheme, but since non-committers can't close
> obsolete JIRA issues anyway, it seems easier to be to update one issue
> with a newer (patch file, zip file) pair than to try to manage lots
> individual issues and expect the ultimate committer to keep the proper
> combination straight.

There was no patch/zip file in the Uber Bug. And JIRA easily has the 
capability to represent UberBugs without closing the individual bugs. I 
have updated to 
reflect this, and had the individual bug(s) been kept open -- which my 
original e-mail suggested -- then it would still be possible to group 
the bugs together and then tick them off individually, instead of 
having a mess of closed bugs and the one UberBug open.

I have instead provided (in Geronimo-66) the 175k of patches I have 
written over the weekend as several files (patch of src/java, patch of 
src/test, jar of src/test/javax/mail/internet, jar of 
src/test/javax/mail) which the bug's current assigner can use if he 
wants to apply the changes in bulk. However, with this amount of code 
IMHO I feel that this should not be performed as a single CVS commit; I 
am happy to be wrong about this.

The big problem IMHO is that I am not just providing small patches for 
existing code; there is a lot of new code involved. Partly this is 
because as a non-commiter this is the only way I can get code across; 
I've also given up any further thoughts of being a committer in any 
case because my brash outlook has clearly managed to annoy a few 
people, for which I apologise. However, I intend to see the JavaMail 
implementation through and make sure that the framework is suitably 
well finished.


View raw message