Re: [picocontainer-dev] patches for *full* binding-annotation capability

Paul Hammant <[email protected]>
Newsgroups gmane.comp.java.picocontainer.devel
Message-ID <[email protected]>
On Nov 29, 2007, at 6:59 AM, Mauro Talevi wrote:

> Konstantin Priblouda wrote:
>>> In this case, Konstantin has a potentially large
>>> change to merge  back.  If I applied my change to trunk first, it
>>> will be quite hard  for him.  He already has a moderate risk of
>>> not-completing his goal,  it'll be worse if I go off in a  
>>> divergent direction
>>> on trunk.
>>> If Konstantin is as respectful (he's a 'good egg')
>>> he'll take a look  at the patch and suggest that its mergeable after
>>> his change, or  before it, or accomotate the same changes in his
>>> branch (chasing the  JasonsTestCase 'specification')
>> well, merge will be not smooth and easy - because your
>> patch also tangles parameter stuff ( which is under
>> heavy refactoring now )  - but possible.
>
> Right a few comments:
>
> - IMO, breaking unit tests should not be acceptable under refactor  
> (except for very specific and special cases, but not wholesale  
> breaking).  If tests don't pass - refactor should not be committed.
>
> - Living in diverging and separate branch is also not good practice.

well i'm guilty of that for the baby-steps branch too.....

> A refactor branch is good to prove a point, to test a new idea,  
> etc ...
> but once it's accepted it should be merged back to trunk.
>
> - Trying to do too much at once is always going to cause problems.
> What is the use case we are trying to deal with in the refactor  
> branch?
> We should try to identifying smaller refactors if possible.

One outcome is that Konstantin has learned what the desired final  
state is, and then performs it again as a series of refactorings on  
trunk with no tests breaking at any point.  He already knows the risk  
that he may get himself in a knot on the other branch that he can't  
get out of :-)


>
> As we are heading for apache merge - we need to decide what the  
> cutoff point will be.

Agree.

Konstantin - in principal - how unhappy would you be with reapplying  
the changes @ apache based on the wisdom you gleaned from  
experimentation ?

- Paul

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.