[Mageia-dev] Freeze Push Question: pulseaudio

[Michael Scherer]

Le lundi 12 mars 2012 à 17:25 +0200, Anssi Hannula a écrit :
> 12.03.2012 00:32, Colin Guthrie kirjoitti:
> > Hi,
> 
> Hi,
> 
> > We're aiming to get a PA 2.0 release out very soon (within the next 4
> > weeks).
> > 
> [...]
> > Can this go it? I think it's worth it.
> 
> I think pulseaudio is an acceptable candidate for exception here, mainly
> because
> - it fixes some big audio usability issues (that will only affect more
>   and more systems during MGA2 lifetime) with the new features, and
> - our package maintainer is the upstream maintainer as well, allowing
>   efficient handling of any bugreports.
> 
> However, I know I'm probably more lax here than others, so this requires
> the input of other release managers before a decision.

For the sake of documenting :

- I have seen that Ubuntu precise still ship 1.1, and they aim for a
much longer support than us ( iirc, 5 years this time ). They also plan
to release 1 week before us :
https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule

- Fedora, also usually shipping latest version ( or even shipping git
snapshot of the glibc during the freeze ), do not have it in rawhide for
now, and not in Fedora 17. The next release is 1 week after us :
https://fedoraproject.org/wiki/Releases/17/Schedule

While Ubuntu do not ship kernel 3.3 in Precise ( but have backported the
jack detection stuff ), Fedora 17 does have it.

So both of them would benefit from shipping PA 2.0 instead of 1.1, and
they didn't chose to do so. They also have likely more people working on
it, and likely a wider array of testers than us. 

However, ubuntu decide to use some kind of patches to PA for the jack
detection part.


The next issue I have is that beside adding bug fixes, that's still a
2.0. While version number are just version number, as said on
http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/1.0 , we do
not have much information on what got changed, and the current page is
rather scarce :
http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/ReleasePlanning

So I personally cannot evaluate how disturbing they would be, or what
they would impact. And sorry, I cannot say "yes" if I think I have not
enough information to evaluate. 

That was my 2nd point.


The third point is that you say you will revert if there is a problem,
but I would make sure that we clearly define what is a problem in a way
that do not suffer from any problem of interpretation. Because if we are
not clear now, we will just push the discussion to later and that's not
the moment usually. 
So I want to make sure that we all fully agree on what would trigger a
reverse before even thinking to say "yes" to the request. Because
despite asking during meeting, not everybody was on the same wavelength
for version freeze, and I see no reason to have the same problem a 2nd
time. And I want to make sure that if we revert, there will be no last
minute negotiation, no matter how harsh would be a revert. 

So i would say 'no' until we have such document. What would be in there
is left open. For example, one of the criteria could be a deadline for
the release of 2.0. If the release slip only of 1 second, that's too
late and we revert. The current target date is 26/03, and we have our
release freeze on 07/04. So I would say that if PA is not released on
26/03, that's too late. 

Or we can say "if there is 1 bug written as critical on our bugzilla, or
the one of PA and not fixed on XX". Or anything.

Without clear conditions being agreed first, I would say "no", that's my
3rd reason.


And while I do not doubt this would be really useful for free software
to have a bunch of testers with our users, and that free software
benefit from shipping RC in distribution, I still think that the beta
are here to fix our bugs rather than those of upstream, and that our
users are not guinea pigs for upstream. That's not exactly what we
promised to them, and for that reason alone, I would also say "no" for
now, and that's a 4th reason.


Finally, I would like to remind that pulseaudio is basically installed
on every installation besides servers, and is critical to the sound
infrastructure. And so, just for the fact that this is central, it
should not be version upgraded if that was not really planned, just for
a feature, for simple risk prevention. We were praised for being stable
just because we basically did several months of debug, and I think we
should strive to keep that reputation, by reusing the same simple recipe
( ie, being cautious and do really more test ). Being rock solid stable
is the only thing where we seems to all agree in our previous
discussion.  


And being central to both KDE and GNOME, it would be present on the
livecd and would not be upgraded  and as such, and because some people
use them as liveusb ( ie, without any upgrade ), we cannot treat this as
"we can upgrade later if it slip", because we cannot for some people. 

And as a side note, I would also remind that some people ( like Pierre
Jarillon, for example ) complained there is _too_ much to download after
a first installation, and why we shouldn't reduce the number of bugfixes
for that, we can at least try to not plan to have more of them.

And that's my 5th reason.


So yes, I understand that you would like to push feature so it benefit
to people. All upstream developers want that, all packagers want that.
I would have loved to have the latest apache on our server for next
upgrade, I would have loved to have systemd sooner for the buildsystem,
or indeed, having the latest PA for the various bluez/A2DP fix
 Heck I would be sure that we have latest apache on our servers, as this
would allow to have a cleaner , contrary to what people may think, no
one actively work to break computers of others. I see that you think you
would be able to properly handle everything. Because everybody think
this. Yet, you would be alone on this on our side, and that's also a
risk. If you were too busy to push PA sooner, and see that kernel 3.3
was planned to be the final, then there is a high chance that you would
be too busy again.


So for thoses 5 reasons, I would say "no", even if I would rather see
this just for free software advancement. 
-- 
Michael Scherer