[pulseaudio-discuss] 3.0 release schedule
david.henningsson at canonical.com
Fri Jun 29 00:21:11 PDT 2012
On 06/28/2012 04:26 PM, Arun Raghavan wrote:
> Sorry it's taken me so long to reply.
Better late than never ;-)
> First, my original rationale while proposing a release schedule: there
> are too many players that I'd like to keep happy, including Ubuntu,
> Fedora, GNOME and KDE.
I understand this point but I don't agree with it. We are, after all, a
freedesktop project, and as such it makes sense to try to align with the
bigger desktops. (And get Ubuntu and Fedora alignment as a bonus.) IMO.
> A 4 month release cycle means that picking up the
> most recent release will never gives each project/distro a version
> that's too stale (<=4 months) to depend on, and we don't have to tie
> ourselves to any other project's release schedule. This is why I'd
> rather have 4 months from release date to release date, and work harder
> at trying to keep within that schedule (i.e., I stick by the September
> release I proposed).
> On the other hand, I'm not keen on doing less than 4 months between
> releases. A shorter release cycle means there is a smaller "merge
> window" to pull in patches and test, and (debatably) more time in
> freezes. IMHO, 4 months allows us to strike a balance between release
> often, and leave enough time to merge big patch sets, test and be
> reasonably confident that they work well.
> Now as for how do we decide release blockers -- it's really a judgement
> call between all of us, and I think we've done a good job on 1.0 and
> 2.0. For feature blockers that don't look like they'll be completed, we
> just drop blocker status. For bugs and regressions, we fix them. Every
> crasher is not a blocker -- there are cases where we have no means of
> reproducing some crashers, in which case blocking on those would be
So, here is where it all falls down. I didn't at all see a rationale in
what bugs were picked as release blockers for 2.0. They appeared more or
less randomly picked to me. :-(
In addition, "bugs and regressions, we fix them" sounds good, as so does
"work harder at trying to keep within that schedule". But it also sounds
more like vision than practical reality.
I fail to see how we're going to make those goals with the limited
manpower we have, especially both goals in combination. Which one of
those statements will take priority, when we both have bugs, and are
closing in on our release schedule?
To be slightly more constructive, how about making the blocker
requirement more strict; like: it should affect several users, and in a
pretty annoying way. That's still a bit unclear, but at least we know
that "one user having a problem with an unusual module or unusual
hardware" would not block a release. That does not stop us from trying
to fix such bugs before the release, of course, as our times (and
Also; a person marking a bug as a release blocker, is also responsible
for making sure it gets fixed in time, possibly by delegating the
responsibility to someone else.
It could also make sense to have IRC meeting every week during the
freeze period to catch stalled release blockers, reassign bugs and so
on. Do you think that type of steering would be feasible, or would you
start to feel like it was just another job and less fun to contribute?
> Finally, David (and all other distro folks) -- we've been pretty open to
> doing point releases with stability fixes if required. So if you think
> having one would be good, just bring it up. It isn't too hard to roll
> these out, and if it makes people's lives simpler, I'm all for it. If
> not explicitly requested, the idea is that we'll only make them for
> regressions or major bugs in a x.0 release.
I'm okay with that.
David Henningsson, Canonical Ltd.
More information about the pulseaudio-discuss