forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <>
Subject Re: [Proposal] Development process and a stable trunk
Date Sat, 27 Aug 2005 12:54:53 GMT
On 8/26/05, Ross Gardler <> wrote:
> 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).

We've talked about this before and last time the only thing I had
heartburn with was "always releasable" trunk as it implies an "Always
Branch" system and I think that's overly rigid and runs counter to our
community goals.  A reasonably stable trunk is a good goal.  Well
documented to the extent possible - if something is still under heavy
development then time shouldn't be wasted documenting yet (beyond that
which would allow other devs to check it out).  Heavy development in
the trunk?  Yes, if it's not causing the trunk to be unstable, then

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

Develop all major changes and new features *that may make the trunk
unstable* in separate branches maybe.  As written, I think this would
lead to fracturing in a couple ways.  1) devs wouldn't check-out all
the other branches and new stuff would be sole-developed even more so
than some things are now; 2) bleeding-edge users won't get into
checking out multiple branches to checkout new functionality (i.e. no

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

I think we agreed to these goals (more or less):
1) a stable trunk (ie. no "hoop-jumping" to build and run). 
2) a branch for anything that would violate goal #1
3) each branch in #2 should be independent features (so that each can
merge separately)

My take on what's being suggested goes well-beyond this but maybe I'm
reading too much into it.

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

I don't think we're mature enough for that.  At least, I've not seen a
robust enough test harness around for it.
> >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

Encouraging such on the project would lead, in my opinion, to a
fractured community.  People naturally tend to prioritize email based
on the subject line, but supporting that through branch prefixes or
the like would lead to several "mini-projects".  Heck, people might
even set up email filters to only look at "their" branch -- not good. 
I think instead we need folks periodically reminding everyone to write
good archive/mailbox-friendly subject lines.

View raw message