Should developers run current ? (was: XDM and X)
brian at Awfulhak.org
Sun Aug 5 01:26:34 BST 2001
I've cc'd freebsd-current here.
This is a followup to a small thread on the UK user group list about
the stability of -stable.
Joe Karthauser <joe at tao.org.uk> wrote:
> On Sat, Aug 04, 2001 at 02:42:44PM +0100, Nik Clayton wrote:
> > This hasn't suddenly changed in FreeBSD -- the -current/-stable branches
> > have worked like this since at least the 2.x days. It's always been the
> > case that if you're using FreeBSD in a production environment you should
> > deploy any new version on to test machines first, and make sure that
> > it works in your environment.
> I agree. Over the years I've updated many production servers to
> -stable, and of course periodically things break, I remember having
> major difficulties when ------------------------ r caused regular panics
> :) On the otherhand the majority of changes to -stable are for
> subsystems and rarely affect the stability of the entire machine. For
> my uses that was sufficient.
Something has changed.
IMHO the developer base has been segregated in the last year, mainly
due to the the part-real, part-perceived instability of -current.
There now seem to be two categories of developer:
o The developer that's too dumb/stupid/smart/proud/lazy to run
-stable and will keep fighting any problems that turn up in
o The developer that's probably been hit by one of the nastier
-current bugs in the past year and has decided (on quite practical
grounds) that it's better to develop under -stable.
I believe this to be a bad thing.
Back in the old days -stable was reserved for bug fixes and some
features/enhancements. ABI and API changes weren't allowed. When
someone made a mistake, they got the same clout across the back of
the head that they do now, but things didn't break that often because
relatively less was MFC'd.
Now, because people are actively developing on -stable, they really
need to push their work back into -stable so that they don't have to
manage local source trees, trees that become more and more fragile as
time passes. Because of this, -stable is now pretty similar to the
-current we had a couple of years ago.... something that breaks a bit
now and again, but not to a major degree as things should really be
shaken out to some extent before they're committed there.
-stable is no longer a branch that you can follow with a production
system -- it's too risky. To this end, the RELEASE branches have
been created. The release branches kind of address the problem
because what's merged into them is kept to a minimum and is
controlled by a few individuals that will not bend it's charter.
There are downfalls to this system though - namely that each minor
release upgrade contains huge numbers of feature additions/enhancements,
making it difficult for people to regression-test production systems.
Personally, I believe that the developers that are now
developing under -stable should simply be lured back onto -current.
Doing this may be enough to make -stable stable again -- if
developers have no big incentive or requirement to have their code
in -stable, but just have the overheads of having to merge it and
read the -stable list, it may tip the balance back towards how
things worked before.
I appreciate that there are a huge number of issues -- things such as
-current carrying so many enhancements that a major release upgrade
becomes an enormous task. I believe there should be a balance
somewhere, and to get closer to that balance, we need to attract our
developers back to -current.
Brian <brian at freebsd-services.com> <brian at Awfulhak.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
More information about the Ukfreebsd