forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: [Proposal] Development process and a stable trunk
Date Sat, 27 Aug 2005 05:33:09 GMT
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 
> > committers
> > 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 
> links.

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.

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

> >4 Create a new release whenever such a merger has taken place so that
> > new functionalities become quickly available to new users and can be
> > stress tested in a production environment without too many changes
> > to consider as a source for potential problems.
> -1 for the same reason as above, some branches will be for minor changes 
> in functionality. However, we have already agreed, in principle, to do 
> more frequent releases. I believe the intent of your suggestion here is 
> aligned with that so I agree with the intent.

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

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

Don't use the "ignore" word. I agree with Thorsten that
that can be damaging to community.

Wouldn't a well-chosen subject title suffice.


View raw message