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
