What about this earlier reply? Could this be a solution? Lennart?
Warren Togami
wtogami@xxxxxxxxxx
-------- Original Message --------
Subject: Re: Pulse Audio 0.9.8 - upgrade?
Date: Thu, 10 Jan 2008 22:07:19 -0500
From: Warren Togami <wtogami@xxxxxxxxxx>
Reply-To: Development discussions related to Fedora
<fedora-devel-list@xxxxxxxxxx>
To: Development discussions related to Fedora
<fedora-devel-list@xxxxxxxxxx>, Lennart Poettering <lennart@xxxxxxxxxxxxxx>
Lennart Poettering wrote:
I discussed the whole situation with Lubomir a while back, when I last
updated the packages for Rawhide. Thing is: right now we don't have a
real policy on what kind of updates should be pushed into already
released releases and what updates shouldn't (but there's a draft, or
something? don't really remember, didn't really follow this). My
understanding is that no big updates should be pushed to released
versions, but bugfixes should. (I used to follow Debian
before I joined RH, and their policy is very strict on this stuff, and
I believe that makes sense).
So, looking on 0.9.7-pre, on 0.9.7-final and 0.9.8, I decided that the
changes are not really suited for an updated package for an already
released distribution, since they are almost exclusively new features,
and only very few relevant bugfixes.
I guess this is the classical distribution dilemma: are the new
features or the stability more important? Whatever way I decide, I'll
make some people unhappy.
Long story short: The changes to 0.9.7 are no bugfixes, those to 0.9.8
are invasive. So I believe this better stays out of an already
released distribution.
And then, you can always run Rawhide. It has 0.9.8. And has had it for
quite a while.
Lennart
As a general rule, version upgrades with new features are NOT disallowed
in Fedora. Version upgrades with new features are introduced in a
controlled and careful manner only after heavy testing. For example,
you might see several kernel rebases during a Fedora release lifetime
like 2.6.22 -> 2.6.23 -> 2.6.24.
Version upgrades that massively break ABI are disallowed during a stable
Fedora release. For example, we never do a rebase to a newer openssl
version during a stable release because they always break their so-name
ABI revision, and far too many applications depend on the existing
so-name ABI.
Does upgrading from 0.9.7 to 0.9.8 break library ABI with applications
already linked against any pulseaudio library? If not, we should really
explore the possibility of upgrading to a newer pulseaudio version in
Fedora 8.
http://people.redhat.com/davej/kernels/Fedora/f8/
By explore the possibilty, I mean doing a test build of pulseaudio-0.9.8
for F8 and putting it into a side repository similar to davej's
un-official test kernel repository. This allows folks to opt-in to
easily test your latest pulseaudio on F8 without risking everyone. By
having your own side-repository with F8 pulseuaudio, you can do your own
builds and push new test packages as often as you want for your own test
users. koji's build --scratch option makes it real easy to do test
builds of a single package on all supported Fedora architectures without
it being an official build.
Later when the test users agree that the pulseaudio package in your test
repository is seemingly good, it can be pushed to F8's updates-testing
repository where many thousands of other users who opt-in to that
optional channel will be exposed to it. It can be tested there for a
while before pushing to the public in the stable updates channel. This
multi-layered approach to testing should ensure that the update is of
higher quality than the current F8 pulseaudio.
Pulseaudio made many applications that used to be stable suddenly
unreliable. Apps like pidgin, mplayer, xine, Adobe Flash Player and
many more now have weird pulseaudio related crash issues. There is a
desire to pull in newer pulseaudio versions if bugs are fixed to make it
more stable.
Please let us explore the feasibility of upgrading it in F8?
Warren Togami
wtogami@xxxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
