Moving features from HEAD to testing

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

Matthew Burgess wrote:

>On Sat, 15 May 2004 12:30:15 +0200
>Jeroen Coumans <jeroen at> 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
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
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

More information about the lfs-dev mailing list