Re: The fate of libc5
On 11 Jul 2000, Turbo Fredriksson wrote:
> The talk about 'limit upgradability to two major releases back' gives me
> the creeps!! It would be very sad if we did this... Yes, it will make
> the releases take longer, but some people seem to forget that Debian
> GNU/Linux is _NOT_ about fast releases, we are about _QUALITY_!!! Debian
> have always been the _BEST_ (!!!) UNIXLikeOperatingSystem
It is pretty standard practice. You have to weigh the cost of one
alternative vs. the other. The cost of supporting further back is
that you carry around a lot of baggage. This lowers the quality of
the system as a whole because it makes for more things that can break.
The cost of not supporting further back than two releases is that the rare
user that must upgrade from a "really old" release will have to stage it.
For example, Hamm -> Slink first, Slink -> Potato next. And in the end,
this is going to go smoother, I think, than doing it all in one go, as
Hamm -> Slink is a well trod path and so is Slink -> Potato.
If the # of users having to upgrade from "really old" releases is large,
then it might be argued that it costs less to support them than to not
support them. (I speak of cost in terms of total time spent by the
developer, the support people, and the user.) If the # of users having to
upgrade from "really old" releases is small, then I think you will find
that it's time to drop support for the old releases.
> I agree (in some form) that 'really old packages should be removed', but
> I just don't see any (big) point in doing so... It's not that much
> strain on the FTP archive, it keeps the Developer on edge, to remember
> the old versions... And code that have already been written to ease
> upgradability, why throw it away?
I don't think anyone's arguing it's a strain on the ftp archive. I think
it's more a matter of our focus, as you say, on quality. Why carry around
old baggage just so you can say "yes, we are backwards compatible an
infinite number of versions"? Certainly some amount of effort should be
expended to maintain backwards compatibility. But it must have limits, or
you will end up expending much more effort maintaining backwards
compatability than you bargained for. I think you greatly underestimate
how much effort is involved.
I speak as a developer of a large (and closed source ... written for a
vertical market) system where we have complete control over all of the
source, written for a proprietary OS (no, not MS) where the vendor has
complete control over their source. And you would think that in these
circumstances it would be trivial to maintain backwards compatibility back
several versions because of the coherent and centralized planning of the
whole system. Backwards compatibility is built into our quality assurance
procedures, and it is well understood by both the developers and the
support staff. (No, I am not singing the praises of closed source
development. I know very well its flaws.) Well, we do strive to acheive
a high degree of backwards compatibility, and so does the vendor of our
OS. We are reluctant to let go of that backwards compatibility, and
wherever it is feasible, we maintain it. Especially because our clients
often have money in the pot for new features, but rarely have extra money
for unanticipated expenses such as "bringing the OS up to the latest
version" with no obvious tangible benefit to them. But it *isn't* easy to
do that. And at some point, we have to decide to bite the bullet and tell
our clients that we're cutting off support for their outdated version of
the software and that they need to move along. So their political and
economic machinery gets kickstarted and they do upgrade. And in the end,
they enjoy more trouble-free operation of their systems, just as we
promised they would. And, despite the discomfort of being forced to
upgrade, they are, in the end, happy. (Or as happy as clients ever get :)
What does this have to do with Debian? Well, in a round-about way I am
saying that users will always drag their heels about upgrading, and it
really is not in their best interests to do so. On the flip side, there
are factors (like the boss won't pay for it, or it has been running fine
for years, why change it?) that keep users from upgrading their systems,
and out of respect for those real issues, some backwards compatibility is
a nice thing to have. But in the end, users are better served with
reasonably up-to-date software, and it gets harder and harder the further
you get from being current to keep the new stuff working with the old. At
some point you must draw the line, for your developers' sake, and for your
users' sake.
Ben
--
nSLUG http://www.nslug.ns.ca synrg@sanctuary.nslug.ns.ca
Debian http://www.debian.org synrg@debian.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
Reply to: