forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav...." <brightoncomput...@brightontown.com.au>
Subject Re: [Proposal] Development process and a stable trunk
Date Mon, 29 Aug 2005 14:20:43 GMT
Can I ask,

How many people are subscribed to the dev list?
How many of those are regular posters and/or contributors?

The answer is for my curiosity, but also may enlighten myself
and others as to actually how many people are working on this project,
it might have a bearing on expected help/workload.

Gav...

----- Original Message ----- 
From: "Ross Gardler" <rgardler@apache.org>
To: <dev@forrest.apache.org>
Sent: Monday, August 29, 2005 7:46 PM
Subject: Re: [Proposal] Development process and a stable trunk


| 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
|
|
| -- 
| No virus found in this incoming message.
| Checked by AVG Anti-Virus.
| Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 26/08/2005
|
| 



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 26/08/2005


Mime
View raw message