Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Jun 2002 19:27:10 -0400
From:      Garance A Drosihn <drosih@rpi.edu>
To:        Brian Somers <brian@Awfulhak.org>
Cc:        bakul@bitblocks.com, tlambert2@mindspring.com, arch@FreeBSD.ORG
Subject:   Re: Avoiding unnecessary breakage (was Re: Removing wait union)
Message-ID:  <p05111725b922efb11f6f@[128.113.24.47]>
In-Reply-To: <20020604222022.6f935871.brian@Awfulhak.org>
References:  <200206041752.NAA08182@rodney.cnchost.com> <p05111724b922b2b4d44b@[128.113.24.47]> <20020604222022.6f935871.brian@Awfulhak.org>

next in thread | previous in thread | raw e-mail | index | archive | help
At 10:20 PM +0100 6/4/02, Brian Somers wrote:
>On Tue, 4 Jun 2002, Garance A Drosihn <drosih@rpi.edu> wrote:
>  > I hope this is not sounding too sarcastic, because I do agree
>>  with the general idea that we should "avoid unnecessary breakage".
>>  It is pretty easy to say that, but it is hard to actually do it,
>>  while still moving the operating system forward.
>
>Many software vendors would say that a published interface
>can only be removed after two major releases of the software.
>[...]
>
>Personally, I think FreeBSD should adopt such a strategy.

Note that there *is* some attempt to do that, for many of the
changes we do.  That effort, when it happens, still does not
protect us from annoying people with "disruptive" changes.

Note, for instance, that the issue which triggered this thread
was the removal of 'union wait'.  Mike Barcroft wrote some
updates to lpr to handle the complete removal of that.  At
first I was a little uneasy about completely removing it,
but it turns out that freebsd *started* to depreciate that
union a long time ago.  I found that I can compile the
'union-wait-less' changes on freebsd 3.5.1 (the oldest
snapshot I still have running).  And if you look at:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/wait.h

it seems like 'union wait' has been depreciated since 1994!
And yet here we have people all a flutter about how we are
making an incompatible change and we might be breaking ports.

At the same time, it is true that lpr has sat there happily
using that depreciated interface for EIGHT YEARS, until Mike
forced the issue by being willing to actually remove the
union from wait.h.  And that's for a program which is part
of the base freebsd image!

That's what I mean by saying "it's easier to say than to do".
If eight years is not long enough to convert applications,
then how long are we supposed to go?  No matter what you do,
the fact remains that some people (particularly 3rd-party
apps) will not change their source code until you force them
to -- and the moment you *do* force them then you'll get a
thread about "freebsd developers should avoid unnecessary
breakage!".

   - - - -
But again, despite all my passion at defending the 'union wait'
change, it's also painfully obvious that freebsd has seen other
changes which have not had a nice smooth transition.  In the
above I coyly said that the 'union-wait-less' *changes* can
compile on freebsd 3.5.1.  That is all well and good, but the
full story is that present version of lpr can *not* compile
on 3.5.1, because of the way the INET6 changes where handled.

So, in short (who? me? short?), I think there are changes where
FreeBSD does a good job at trying to soften the transition --
and that we do not give ourselves enough credit when we do that.
At the same time, there are other changes which are more abrupt,
but sometimes the abrupt change is done because mapping a smooth
transition will require a great deal more work.  And with a
volunteer group, it isn't always easy to find people who are
willing to do that extra work.

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05111725b922efb11f6f>