forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [Proposal] Development process and a stable trunk
Date Mon, 29 Aug 2005 11:46:22 GMT
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).


View raw message