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 Fri, 26 Aug 2005 11:29:55 GMT
Ferdinand Soethe wrote:

>I have an uncomfortable gut feeling with the current status of our
>pre-release version and I'd like your feedback on these concerns and
>my suggestions to change our process.
>My concerns with the current situation:
>- in the last few month a number of exciting major projects
>  (location maps, views, i18n, change of cocoon ...)and a number of
>  smaller ones have been developed (which is good!)
>- most of them have not been finished to the point of being releasable
>  and (so it seems to me) will not be for considerable time so it
>  seems like we won't be able to release quickly without a major clean-up
>  effort (which I consider bad).
>- the work-in-progress-state and its (perfectly normal) unfinished
>  documentation make it very hard for people to understand the
>  development version or work with it at any point in time or
>  understand the implications and side effects of each new development.
>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 

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

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

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


A few weeks ago I started working on summarising the many discussions 
like this that we have recently had. I have never found the time to 
finish it, in fact I hardly got started. I'll copy what I have here, I'd 
encourage someone to take this, put it in SVN and add the other details 
from the threads linked to in this draft and the additional stuff 
suggested above.

--- Pre-draft of Development Process ---

This proposal is a summary of the following recent threads

"Project participation and hackability" [1] and [2]
"Using Jira and branches for Project Management" [3]

I also used Cocoons [4] project management wiki page for inspiration.

It is intended to be the starting point not the end game, we should move 
this into a document (any volunteers?) and keep it up to date as we 
learn "on the job". Some of the things in here will prove to be 
unworkable, some will be improved. Lets try them and see how it goes.



To define a project management process that will enable Forrest to 
continue to grow without becoming a totally chaotic environemnt.

To create a structure to progect management that is not restricitve to 
the Open Source development process

To define processes that, when followed correctly, will reduce the 
effort required for Forrest developers to participate effectively, that 
is, to not overly burden developers will project management tasks

To create a single point of reference for accepted best practices within 
the Forrest development community


Forrest is growing rapidly in many directions. We have a far larger 
developer base than just a few months ago, we have a code base that is 
expanding in many directions and we have a user base that are applying 
Forrest to an increasingly diverse range of problems.

This expansion has resulted in a great deal of new ideas from the 
project and inputs to the project. Far more than can possibly be managed 
by any single developer. As a result "virtual" teams are emerging within 
the community, each focussing on different parts of the Forrest product. 
 Communication and understanding between these "teams" is excellent, but 
the volume of mail passing through our Forrest mailing lists is becoming 
unmanageable. As a result developers become selective of which threads 
they track in detail which ultimately results in some duplication of 
discussion at the overlap points between functionality.

It appears that the Forrest project has expanded to the point at which 
we need to maintain an overview document about the project, the work 
being carried out, the work planned and the integration of this work 
into the core product.


Using Branches for New Functionlaity



View raw message