[Mageia-dev] Freeze Push Question: pulseaudio

[Dimitrios Glentadakis]

Στις Δευτέρα 12 Μάρτιος 2012 22:04:46 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. 
> 

I think in the case of the pulseaudio we can trust Colin and not what other distributions doing, and especially for Ubuntu.  As i dont have an opinion for fedora i can say that for a long time Ubuntu users suffers with pulseaudio when Mandriva users not. It is an opinion that i made reading forums.

I was very satisfied when i read an article from the chief editor in the Greek version of Linux Inside the 21/02/10. This magazine is Debian/Ubuntu oriented so if there is a compliment for Mandriva is really objective.

In this article it says that the best KDE distribution is Mandriva and between other arguments there is the support pulseaudio for KDE by Colin:
«[...]It has stereo sound system. The classic problem with other distributions is that KDE4 does not have sound in applications like Amarok or have but with conditions. In Mandriva, thanks to PulseAudio and the work that Colin do is not such a problem. And from what i see, in the next version will be even better [...]»

http://www.linuxinside.gr/content/ποια-είναι-η-καλύτερη-διανομή-για-kde 
Greek

http://translate.google.com/translate?hl=el&sl=el&tl=en&u=http%3A%2F%2Fwww.linuxinside.gr%2Fcontent%2F%25CF%2580%25CE%25BF%25CE%25B9%25CE%25B1-%25CE%25B5%25CE%25AF%25CE%25BD%25CE%25B1%25CE%25B9-%25CE%25B7-%25CE%25BA%25CE%25B1%25CE%25BB%25CF%258D%25CF%2584%25CE%25B5%25CF%2581%25CE%25B7-%25CE%25B4%25CE%25B9%25CE%25B1%25CE%25BD%25CE%25BF%25CE%25BC%25CE%25AE-%25CE%25B3%25CE%25B9%25CE%25B1-kde
Google translation to English



So may be we dont have always take as example (and as a rule) what others do but first trust our stuff. 

I wanted to bring this argument in the discussion. Personally, i try to have an open mind (i say "try" because it is nt a fact being objective every time, it is something that needs an effort) and examine all arguments from anyone. 


-- 
Dimitrios Glentadakis