1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
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>
|
