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
