[Mageia-dev] Freeze Push Question: pulseaudio

Mon Mar 12 22:04:46 CET 2012

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
+
+