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

Mauro Talevi <[email protected]>
Newsgroups gmane.comp.java.picocontainer.devel
Message-ID <[email protected]>
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.
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.

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


Cheers


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