[Fedora-music-list] [PlanetCCRMA] about Fedora updates

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Tue Mar 9 19:43:57 UTC 2010

On Tue, 2010-03-09 at 03:50 -0500, Orcan Ogetbil wrote:
> On Tue, Mar 9, 2010 at 3:34 AM, Luis Garrido wrote:
> >> The main reason that I am writing is to ask you about your take on our
> >> update strategy in Fedora. Currently, there is a heated discussion in
> >> Fedora-devel mailing list about update policies. It might happen that
> >> our updates policy might change to a more conservative one.
> >
> > I thought Fedora filled RedHat's niche for "keeping up with the new
> > features even if stability suffers a bit" distributions. What is "more
> > conservative", exactly?
> >
> There are mixed opinions. Some say security and bugfixes but no
> enhancement updates. 

Weird (see below) 

> Some even go up to pushing security fixes only.

Even weirder. We could have frozen functionality for 6 months worst
case! Maybe in mature applications like apache that is reasonable, but
in what I consider to be the fast moving world of audio apps that would
be too long a wait - and the wait would be for a _full_ update of the os
just to get functionality updates for audio apps. Maybe that is part of
the purpose of a more stable Fedora? To force users to update to the
latest? I have to get some time to read the thread (I have not been
following up on the Fedora list, too busy...). 

> Here is a proposal that will be discussed in tomorrow's steering
> committee meeting:
>    http://lists.fedoraproject.org/pipermail/devel/2010-March/132730.html

Well, I wonder if maybe Fedora is going from one extreme to the other.
Some updates in the past have been extremely disruptive to users with no
intention whatsoever of fixing them after the disruption was made
clear[*]. On one hand stopping that kind of major update would be good. 

On the other hand maybe some would complain that an upgrade to ardour
that adds functionality should not hit stable until the next release of

> No conclusion has been reached for the time being.
> > A mature-ish Fedora (i.e., one version below the the current one but
> > still on maintenance, between 6- and 12-months old) is usually a good
> > trade-off. You will always have to deal with some problematic stuff or
> > another, putting down small fires, but that's the blood in the
> > bleeding edge, people should be aware of that when they choose this
> > kind of distro. If you value rock-solid stability over new features go
> > RHEL or CentOS (which I do for my servers.)
> >
> :) These were the main arguments that some more "adventurous" package
> maintainers like me came up with.
> I just wanted to hear you folks' opinions, as that's what matters for me most.

As a reference, historically (since 2001) Planet CCRMA has always
updated to the latest versions of major packages very fast. Not so much
lately, of course (I have not been as responsive as in the past and the
packages that have migrated to Fedora lag behind because of the more
strict release guidelines there). I used to push updates to major
packages within a few days of their release. Some light internal testing
and off they went. Maybe a bit too much :-) 

But I don't think there was a major protest in the list about that
policy, rather the opposite, users were usually happy about having the
latest and greatest available sooner rather than later. 

There was/is always the option of _not_ upgrading and some users have
kept obsolete but working setups for years. 

And, BTW, I think you are doing a great job of maintaining the packages!

-- Fernando

[*] An example is the firewire stack. It was broken in fc7 and it is
still not usable for audio purposes AFAIK unless you run the Planet
CCRMA kernel - maybe that has changed? The end goal is noble (a better
firewire stack) but the way to get there did not take into consideration
a whole class of users and devices. I think many former Planet CCRMA
users did not (wisely) wait for a fix, and migrated elsewhere. Something
similar can be said of pulseaudio. Again, a noble and necessary goal,
but the way there was/is not the most stable from the point of view of
the users. So, basic infrastructure can be broken at will but userland
packages can't introduce new features??

More information about the music mailing list