Moving features from HEAD to testing

Matthew Burgess matthew at
Sat May 15 04:33:55 PDT 2004

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. 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.

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.  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

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?



More information about the lfs-dev mailing list