forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject [Proposal] Development process and a stable trunk
Date Fri, 26 Aug 2005 05:28:00 GMT

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.

3 Discuss and vote one merging each branch back into trunk.

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.

  This would also make testing of new releases a lot more focussed.

Obviously plugins would not require a separate branch as they already
have the whiteboard and a similar process. However, I would like to
suggest an optional step 4 for important plugins (like views).

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.

  Only take issues to the list as a general topic when
  interface issues or planned architectural changes
  require input from the general community or the development
  team is ready to show and explain their work and suggest a merger.


Ferdinand Soethe

View raw message