diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-March/013005.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-March/013005.html | 229 |
1 files changed, 229 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-March/013005.html b/zarb-ml/mageia-dev/2012-March/013005.html new file mode 100644 index 000000000..293f936f6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-March/013005.html @@ -0,0 +1,229 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Freeze Push Question: pulseaudio + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Freeze%20Push%20Question%3A%20pulseaudio&In-Reply-To=%3C1331586286.1167.342.camel%40liliana.cdg.redhat.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="012980.html"> + <LINK REL="Next" HREF="013011.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Freeze Push Question: pulseaudio</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Freeze%20Push%20Question%3A%20pulseaudio&In-Reply-To=%3C1331586286.1167.342.camel%40liliana.cdg.redhat.com%3E" + TITLE="[Mageia-dev] Freeze Push Question: pulseaudio">misc at zarb.org + </A><BR> + <I>Mon Mar 12 22:04:46 CET 2012</I> + <P><UL> + <LI>Previous message: <A HREF="012980.html">[Mageia-dev] Freeze Push Question: pulseaudio +</A></li> + <LI>Next message: <A HREF="013011.html">[Mageia-dev] Freeze Push Question: pulseaudio +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#13005">[ date ]</a> + <a href="thread.html#13005">[ thread ]</a> + <a href="subject.html#13005">[ subject ]</a> + <a href="author.html#13005">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le lundi 12 mars 2012 à 17:25 +0200, Anssi Hannula a écrit : +><i> 12.03.2012 00:32, Colin Guthrie kirjoitti: +</I>><i> > Hi, +</I>><i> +</I>><i> Hi, +</I>><i> +</I>><i> > We're aiming to get a PA 2.0 release out very soon (within the next 4 +</I>><i> > weeks). +</I>><i> > +</I>><i> [...] +</I>><i> > Can this go it? I think it's worth it. +</I>><i> +</I>><i> I think pulseaudio is an acceptable candidate for exception here, mainly +</I>><i> because +</I>><i> - it fixes some big audio usability issues (that will only affect more +</I>><i> and more systems during MGA2 lifetime) with the new features, and +</I>><i> - our package maintainer is the upstream maintainer as well, allowing +</I>><i> efficient handling of any bugreports. +</I>><i> +</I>><i> However, I know I'm probably more lax here than others, so this requires +</I>><i> the input of other release managers before a decision. +</I> +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 : +<A HREF="https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule">https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule</A> + +- 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 : +<A HREF="https://fedoraproject.org/wiki/Releases/17/Schedule">https://fedoraproject.org/wiki/Releases/17/Schedule</A> + +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 +<A HREF="http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/1.0">http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/1.0</A> , we do +not have much information on what got changed, and the current page is +rather scarce : +<A HREF="http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/ReleasePlanning">http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/ReleasePlanning</A> + +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 + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="012980.html">[Mageia-dev] Freeze Push Question: pulseaudio +</A></li> + <LI>Next message: <A HREF="013011.html">[Mageia-dev] Freeze Push Question: pulseaudio +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#13005">[ date ]</a> + <a href="thread.html#13005">[ thread ]</a> + <a href="subject.html#13005">[ subject ]</a> + <a href="author.html#13005">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |