forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <ferdin...@apache.org>
Subject Re: [Proposal] Development process and a stable trunk
Date Mon, 29 Aug 2005 10:47:02 GMT

Thanks everybody for taking the time to respond and giving me a change
to re-think and refine my own thoughts on these issues.

Here are some comments for a start:

- Ignoring of threads (or developments)

  I'm sorry to say this but I'm simply not able to read everything that's
  on this list all the time. And even though this might have to do
  with going kayaking too often in my case :-), I think that with growing
  volume of project and list this will happen to most of us sooner or
  later.

  For me prioritizing stuff in this list is a necessity rather
  than a choice. And at the moment I can never tell the relevance of a
  thread to Forrest as a hole.

  I know that it would be nice if all of us could follow all the
  threads, but honestly, is that realistic?

  Also: A lot of people might join the list without the interest or
  the capacity to follow all our discussion from the start. Following
  new developments from when a merger is proposed gives them a good interface to
  cutting-edge forrest development without the bloodloss :-).
  
- When to branch

  After considering your responses I realize that I need to refine the
  criteria for branching:

  Changes should happen in a branch when they

  - change (not fix) to output
  - require additional or different input
  - change (not add) existing configuration options

  The reason behind this demand is, that all these changes require
  users and developers to adjust their applications or their coding
  work in progress. So in order to do that efficiently they should
  have well defined, finalized and properly documented changes to deal
  with.

  In addition I would suggest branching also
  
  - when the internal workings
    of a module are altered in a major way.

  The reason for this being that anybody also working on, extending or
  even debugging such a module does not get in the middle of somebody
  else's major change or has to guesswork about the function of some
  undocumented new piece of code.

- Vote on merging branches

  I have no problem with the lazy consensus model her. What is more
  important to me is that fact that at least some developers not
  involved in the implementation should have looked at (not just 'have
  had a chance to look at') and tried the new functionality.

  Now I know that this is hard because you have to get somebody to do
  this and perhaps even wait for them to do it. But on the other hand
  I expect this to have a couple of useful side effects:

  - Documentation and value of the new developed functionality have to
    be properly balanced or nobody will do the testing.

  - The time waiting for a tester is often useful to rethink and
    refine the solution and perhaps even improve on the docs.

    
--
Ferdinand Soethe


Mime
View raw message