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" <[EMAIL PROTECTED]> 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
