forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [Proposal] Development process and a stable trunk
Date Sat, 27 Aug 2005 13:57:11 GMT
David Crossley wrote:
> Ross Gardler wrote:
>>Ferdinand Soethe wrote:
>>>What I'd like to see in the future:
>>>1 Adjust our development process so that the current development
>>>version (I think this is called 'trunk') is always releasable,
>>>stable and _well documented_ (meaning complete and correct, not well
>>>written or suitable for a dummy user).
>>>2 Develop all major changes and new features in separate branches that
>>>will only be merged back into trunk when they are stable
>>>and well documented (not talking refined documentation but good enough
>>>that a technical writer could work with it) and a good number of 
>>>not involved in the process have reviewed and tested them.
>>Both 1 and 2 are already agreed in principle, we just have to action it 
>>by creating the infrastructure and processes, see end of this mail for 
> We did discuss this earlier and seemed to be in agreement.
> I know that documentation is a good thing, but i don't
> see how we can measure it enough to be able to deny
> a merge. Perhaps if there is at least some docs then
> merge is okay.

+1 - not enough docs could be one reason why someone would object to a 
mere (see below)

>>>3 Discuss and vote one merging each branch back into trunk.
>>-1. We only need to discuss major contributions. You will see in the 
>>above linked thread that we are talking about using branches for *all* 
>>work that may break existing functionality, however votes should only be 
>>taken on major functionality.
>>Instead of a vote what should happen is that someone announces they are 
>>going to merge into trunk unless someone objects (i.e. lazy consensus)
> I agree, but they also need to allow time for
> the world to turn a bit so that that we all have
> time to raise concerns.

+1 - 3 complete revolutions of the planet is the "usual" on other projects.


>>>This would also make testing of new releases a lot more focussed.
>>I would like to go a step further and say we do not merge branches until 
>>we have automated tests for the new features and all existing tests pass.
> Tests would be good, but as yet we don't have a good enough
> testing framework to be so rigorous.

True, so we need to create one. The absence of one should not prevent us 
from moving forwards with Ferdinands proposal, but it should be 
considered an important addition to the process.

>>>5 As a supportive measure, clearly mark threads in this list when they
>>>deal with a particular branch so that people not working on that
>>>issue can safely ignore it.
> Don't use the "ignore" word. I agree with Thorsten that
> that can be damaging to community.

+1 - I had interpreted "ignore" in the context of lazy consensu, I agree 
nothing should be ignored in the sense of no notice is taken.

> Wouldn't a well-chosen subject title suffice.



View raw message