[pulseaudio-discuss] 3.0 release schedule

[David Henningsson]

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
> silly.

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 
interests) permit.
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.
https://launchpad.net/~diwic