geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Pearcey" <ke...@loon.org.uk>
Subject RE: Closing items 49-56,58-65 as duplicate
Date Tue, 02 Sep 2003 17:07:36 GMT
 
> 	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.
> 
> 	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.

So perhaps we should break some of Alex's fingers and slow him down. Are you
seriously suggesting that you have a problem dealing with someone breaking
down their work in to distinct pieces to they have better control and
tracking of it?  I suspect this will just force Alex to upload his patches
in a more spread out pattern, thus slowing the general development of that
area.

>	Compare one big patch to 15 little patches.  It's 
> harder to sort through all the little patches and determine 
> how they relate. 
But you can easily sort though one big patch and determine each thing it
does can you? Perhaps you should take the final big patch and see how long
it would take you to break it down into the original 15 components, such
that as a committer you are fully aware of what the changes were.

> It's harder to apply them in the correct order.
Yeah, cause Jira has no dependency stuff to help with that!

> It's harder to make sure they all get applied.
Because if one doesn't the issue can't be re-opened!

> It's harder to figure out which ones obsolete which other ones.
Individual patches don't obsolete each other, they complement themselves.

> 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.

It seems from this that it's the committers that are lazy. I don't see how
Alex taking the time sorting out each distinct change is lazier that a
simple big patch.  

As I understand it Alex used the features of Jira to state what the
dependencies of each were and so perhaps you need to read up on how that
works - plus if the patches are for distinct problems then they have no
relation so can be applied in any order!

> 	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.
> 
> 	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.
> 
> 	But that's just MHO.

Which is clearly different to mine, but then you don't work for me so you
don't have to live by my rules for quality. And that's where I'll leave it.

K.


Mime
View raw message