[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: today's merges

From: Stephen J. Turnbull
Subject: Re: [Gnu-arch-users] Re: today's merges
Date: Mon, 01 Sep 2003 14:53:24 +0900
User-agent: Gnus/5.1001 (Gnus v5.10.1) XEmacs/21.4 (Portable Code, linux)

>>>>> "Andrew" == Andrew Suffield <address@hidden> writes:

    Andrew> Not buggy, per se, just unstable in the classic sense of
    Andrew> the word - it's a target that moves _really_ fast. I don't
    Andrew> have time to chase it. You're better off running from the
    Andrew> daily builds if you need that sort of stuff.


I'm not volunteering, but if someone were willing to make the
judgements about what goes into the semi-stable branch (cf. (2),
below) and support it with a config, would you roll .deb releases
from that?

You see, this has always bothered me about XEmacs's release model.  I
pushed _really_ hard to have a three-branch release process:

1) Stable.  As Tom puts it ``The policy for $STABLE is to fix bugs that
"have to be fixed" -- which isn't precisely defined, but certainly
does not include adding $FEATURE-X.''  Fixing leaks in the plumbing.

2) Development.  Adding features like $FEATURE-X, but requiring that
they be added in ways that have minimal impact on stable features,
rather than doing them in ways that architecturally would be best.
This limits you to features that don't need low-level changes to the
core.  Add a deck in the backyard, but can't change the garage into a
new master bedroom because the plumbing and the electrical work
require rearranging the whole kitchen/garage wall.

3) Research.  Blue sky, anything goes, for feature design.  But
implementations must be architecturally sound, even if that means
ripping out the garage foundations and redoing them to add the new
bedroom with proper underfloor plumbing, wiring, and insulation.

This got vetoed, though, on the grounds that nobody would be willing
to run and work on branch (2), and it would confuse the beta testers
about what was important.  None of which I believe, but I'm a manager
in service of the developers, not vice versa.  :-( [1]

[1]  This is one of the few issues where I still think the developers
were wrong and "management" (me) was right.  :-)

Institute of Policy and Planning Sciences
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]