Should developers run current ? (was: XDM and X)

[Brian Somers]

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:
> >=20
> > 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.
> >=20
> 
> 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 
   -current.

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.

> Joe

-- 
Brian <brian at freebsd-services.com>                <brian at Awfulhak.org>
      http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>