[PlanetCCRMA] about Fedora updates

[Peter Kirn]

I just want to put in my own vote here to say -- no, it's not
necessary to shut down pulseaudio in order to run JACK. It'd be
interesting to have a custom package that ran JACK as a service, I
suppose; I could see this being an interesting way of doing easy-on
performance/installation machines, but even that wouldn't be strictly
necessary.

I've been really impressed with the quality of package maintenance. I
think it's safe to err on the side of more updates, especially if the
updates do a good job of documenting what has changed, so that people
can make an informed decision.

So thanks for the great work.

Peter

On Tue, Mar 9, 2010 at 2:43 PM, Fernando Lopez-Lezcano
<nando at ccrma.stanford.edu> wrote:
> 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
> Fedora?
>
>> 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??
>
>
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
>