forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Project participation and hackability
Date Mon, 27 Jun 2005 11:37:29 GMT
Ross Gardler wrote:
...
> Once we have an RC built we only allow bug fixes in trunk, new features 
> are developer in a branch. 

I wouldn't be that strong. If I'm adding a new feature to the trunk, but 
this does not interfere with prior behaviour, there are no problems.
It's just about keeping the trunk possibly bug-free, as far as the 
developer is concerned.

If we use branches for all new features, we have the problem that nobody 
will check what is happening, like with views. We should really push for 
small reversible changes in the trunk, and use branches only when this 
is not possible (like in a new feature that needs core refactoring).

Smaller changes are more easily testable, reversible, and auditable by 
all. Big commits tend to go by without peer review.

> Subsequent RC's for that release should be 
> made every couple of weeks. Once we have a couple of weeks with no bug 
> fixes we release.
>
> Remember that plugins can have a separate release cycle. So only work on 
> core need move to a branch.

Yup, that's cool :-)

>>>> Furthremore, these branches should merge whenever possible between them
>>>> in a single branch so that they can be coded together, and get merged
>>>> with the trunk only when all developer-known bugs are fixed.
>>>
>>> I understand that there will inevitably be dependencies between
>>> branches but I don't care for merging branches into a single branch
>>> (btw, wouldn't that ultimately become the defacto dev trunk?).
>>
>> There should not be dependencies between branches. If there is, then 
>> it should merge in a single branch.
> 
> But this will prevent complete features being merged with trunk because 
> incomplete features are brought into the branch. All that will happen 
> there is that the branch will get into the state that trunk was in 
> before the 0.7 release and we will split our devs between creating new 
> features in the branch and maintaining trunk (not necessarily a bad 
> thing, but do we have enough devs for this?)

We should not get into a situation in which an incomplete feature merges 
with a more complete branch. This happens when development is too long, 
and people start using the branch as their trunk.

If this is not possible, it's the most incomplete feature that must 
incorporate the changes from the more complete one, not the opposite. 
This frees it from being stopped in merging with the trunk.

...
> In other words, I am +1 for an "always RC quality" or an "always beta 
> quality" (as Nicola said in another reply) trunk. I am also +1 for 
> "alpha" quality branches where necessary.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message