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

2001-08-04 Thread 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED][EMAIL PROTECTED]
  http://www.freebsd-services.com/brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour !  brian@[uk.]OpenBSD.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



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

2001-08-04 Thread Kris Kennaway

On Sun, Aug 05, 2001 at 01:26:34AM +0100, Brian Somers wrote:

 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.

This discussion comes up periodically (usually, once per code freeze
;-)

I don't think the high rate of MFCs mostly occurs because developers
develop on -stable, it's because the branch can't be allowed to
diverge too much from -current or porting of bugfixes becomes
difficult (especially kernel bugfixes, but also other
actively-developed or heavily modified systems).  Many people feel
seem to that the fact that this divergence was allowed to creep in
between the 3.x/4.0-CURRENT branches contributed heavily to the
continued poor stability of the 3.x branch towards the second half of
its release cycle when it should be expected instead to mature and
stabilize.

If the developers all run -current, and -current is incompatible with
-stable, then -stable also suffers in quality.  There's a balance
which needs to be struck.

I run -stable on several systems and regularly upgrade.  I haven't
encountered sudden instability, incompatibility or sudden onset of
problems.  Personally, I don't think things are so bad in -stable
land.

Kris

 PGP signature