Horst H. von Brand wrote:
Are you suggesting that we should never provide an unstable interface
in any of the libraries or scripting modules that we package?
No, I'm saying that necessary changes should be planned, and to the
extent possible, batched at version releases.
That means even more of the bureaucracy that people are so quick to
disparage here...
But just regarding timing the move from rawhide to release, and it would
be less arbitrary if the answer was always 'release at a version
release' unless you are fixing something horribly broken as shipped.
And where that isn't
possible, interface and command line changes to expect should be
published before the update so users and 3rd parties know how to work
around the breakage.
That isn't always obvious to the packager of some piece of infrastructure.
Change GCC, the "normal" applications continue compiling fine (or get fixed
as part of the update in the distributin), but some strange package
somewhere was relying on a GCC bug (or misfeature, or sloppiness) and blows
up when you try to build it. Has happened dozens of times to me, and I'm
still grateful GCC moves forward and becomes more standards-conforming.
Being grateful it moves is one thing. Being surprised when it regresses
mid distro-version is something else. The problem is that every update
is not 'forward'.
Who forces you to push interface-changing updates out of rawhide?
New upstream versions... go talk to them ;-)
That makes sense as a reason to go into rawhide. Why do they have to go
into production before a release point?
If
I wanted today's bugs from an upstream project I'd grab it from there
instead of using a distribution's release version of the code. The
fedora major release cycle is already fast enough anyway.
It is fast /because/ it integrates upstream changes as early as
possible. Can't have fast advances and no change at the same time.
If you want rawhide you can run rawhide. Otherwise what's so important
that it can't wait for a release point?
If some
upstream project can't settle on an interface you are doing your users
a favor by keeping it away from them.
OK. Leave out the kernel, ...
If there were a nexenta-like flavor of fedora (our familiar userland on
top of opensolaris) I'd certainly give it a shot. Otherwise the
overwhelming need to constrain and manage Linux kernel changes keeps
several large corporations in business.
What I'd really
want is for LSB-compliance to someday get to the point where programs
running on Fedora would never need to know that it is fedora at all,
much less the version and last-update-date underneath.
LSB and similar standards mean aiming at the lowest common denominator.
I.e., it might work just fine, but it will certainly waste much of what
Fedora (or any other particular distribution) is all about
If people can't agree that the interfaces/libraries are the right way to
do things, then there's a pretty good chance that they aren't, and that
they will probably change or go away soon. I don't have time to waste
chasing a lot of things that are going to change and break underneath
the things that might depend on them.
Is there someone involved in development that eats his own dog food
(i.e. uses fedora with current updates as infrastructure for some
large project or even in a lab setting with many users)?
I'm using Fedora rawhide daily. Our labs (several hundred users) are
running latest Fedora most of the time (except when the releases fall at
awkward times in our terms).
Do the users ever have things break because libraries changed under
them? Is this the sort of lab where work progresses over years or
decades or where the universe is re-created every semester? The latter
doesn't exactly match the real world.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
