Ferdinand Soethe wrote:
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 :-).
I agree with everything said and feel that this is what the conclusion
of the thread has been.
It is the respopnsbility of the PMC to read *all* commits, not *all*
mails. We should not *ignore* threads though. I tend to read the first
post in a thread, if it is a priority for me I read all subsequent posts
otherwise I skin read the subsequent posts.
I also have filters set up on my mail client that will detect if someone
types my name. So if someone says "I wonder what Ross thinks" or "Ross,
how would this fit into plugins" or something like that my client flags
the message for me.
In addition, as you point out well worded subjects are important. I'm
not sure about prefixing with a branch name since a discussion about
something in a branch is also a discussion about what will end up in
core. So it is no less relevant just because it is in a branch.
- 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 option
In earlier threads (linked to in my prevoius mail) we discussed criteria
for branching. I think the conclusion was that it should be up to the
individual dev do decide. It isn't really possible to create a set of
rules - nothing wrong with examples like those above (and below) though.
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.
+1, I think Tim expressed this as something like a realeasable trunk
does not requrie users to jump through any hoops.
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.
Since all PMC members have a responsability for reading *all* commits,
then (in theory) all developers will ahve watched what was going on in
the branch anyeay. There should be no need for a separate review cycle
before merge.
In my opinion the docs + tests we discussed are more important.
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.
Here you are proposing a formal test process before merging. I'm not
sure how I feel about this. Speaking personally, I don't have the time
to test *all* of other peopls code, they could wait for me for a long
time, this will cause problems. I prefer to trust that they have tested
it sufficiently before commiting and merging.
(longer term I would prefer a proper test suite in Forrest, but that is
a whole different thing and should not delay progress on your proposal).
Ross
