Moving features from HEAD to testing

Tushar Teredesai tushar at linuxfromscratch.org
Sat May 15 08:58:30 PDT 2004


Matthew Burgess wrote:

>On Sat, 15 May 2004 12:30:15 +0200
>Jeroen Coumans <jeroen at linuxfromscratch.org> wrote:
>  
>
>>Tushar Teredesai said the following on 15-05-2004 07:03:
>>    
>>
>>>One shortcoming I see is the anwer to "Who decides what gets merged
>>>from HEAD to "testing" and when that happens?". From the document it
>>>seems that it is only for the maintainers to decide, the commnunity
>>>does not have any say in the matter. IMO, the answer should be
>>>expanded to include the commnunity opinion.
>>>      
>>>
>>Overall, good document, however I share Tushar's concern. Is it
>>possible to establish some ground rules?
>>    
>>
>Well, I purposely omitted mention of the community, because at the
>moment the community simply cannot agree on *anything*, aside from the
>apparent need to constantly flame each other.
>
The community has never agreed on anything (only exception was the 
inclusion of zlib!). But that did not stop the editors from considering 
the technical arguments presented by others, and I don't think it should 
stop now.

In the discussion on hotplug, I have yet to see any mail that is a 
flame. Most of it has been a discussion about the goals of LFS since the 
inclusion of hotplug changes the focus of LFS from a minimal development 
system to a functional one.

>By limiting those who
>actually have the power to authorise a new change then we may actually
>be able to progress the book forward, rather than spend countless months
>debating back and forth and never getting anywhere.
>
>I, of course, *do not* want to see the community left out like this, but
>unless everyone can start showing some more reasonable *discussion*
>abilities and are able to *compromise* a little then we're never
>going to be able to make any changes to the book.  We have to face up to
>the fact that 100% of the community are never going to accept 100% of
>the outcomes of list discussions.
>  
>
Since you are distinguishing the commnunity from the developers, I would 
like to make a rebuttal from as a community member. Even developers 
should be willing to make compromises and not consider that a -1 to 
their proposal is a flame on their efforts or a vote of no-confidence 
against them.

>I'd also like to highlight a fact that may have escaped some people
>recently.  LFS is unlike any other open source project I know of, in
>that the thoughts and opinions of the entire community are
>considered.
>
Which is a very strong point in its favor IMO. The true spirit of democracy.

>The majority of open source projects I've seen have a more
>clear-cut distinction between the development team and their user
>base.  I don't want to instill this kind of separation between the
>development team (editors, etc.) and the members of the lfs-dev
>list, but it may be the only way we will ever be able to progress
>development.
>  
>
I am also not in favor of making lfs-dev an editors only list with 
closed archives.

>Getting a little more back on topic now, the original thought I had on
>merging features from HEAD to testing was to have a "proposal" system. 
>Essentially what would happen would be that the HEAD guys do the initial
>investigation into a new feature/major toolchain revision.  Once it's
>relatively stable then someone (not necessarily them) writes a *short*
>proposal outlining the advantages and disadvantages of that feature,
>with particular regard to the goals of LFS and what is documented in the
>prologue of the book (i.e. what should/shouldn't the end result of LFS
>be).  It would also mention any dependencies that feature has, that
>aren't already in the book, so a more accurate view of the scale of the
>changes can be seen immediately.  The proposal would be posted
>(either here, or made available online) and be open to counter-arguments
>for a period of between 1-2 weeks. These counter-arguments should also
>be in relation to the goals and end results of an LFS system.
>
>By time-limiting the discussion, we ensure that decisions will be made
>in a timely manner (and that decisions *will* be made at all).  By
>limiting the nature of the arguments we move away from the ridiculous
>+1/-1 voting system that is completely worthless in this community, as a
>simple vote tally will never demonstrate any kind of adherence to the
>projects goals/policies.  As mentioned before we'll never achieve 100%
>consensus, and as yet we don't have a policy outlining what % consensus
>is required to carry a change forward.
>
>Was this the kind of thing you were looking for?
>  
>
I agree with the proposal approach and also with the fact that +1/-1 
system is not very useful.

-- 
Tushar Teredesai
   http://linuxfromscratch.org/~tushar/
   http://www.geocities.com/tushar/




More information about the lfs-dev mailing list