[pulseaudio-discuss] 3.0 release schedule

[Tanu Kaskinen]

On Fri, 2012-06-29 at 09:21 +0200, David Henningsson wrote:
> > 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.

There is a class of bugs that are so severe that they just have to be
fixed before the release is made, no matter how long it may take, but
those are very rare (I can't even think of any real-life examples right
now). I guess those are the only "real blocker" bugs. Then there's the
class of "not really a blocker bug, but marked as a blocker anyway"
bugs.

Outside the freeze periods, I generally keep patch review as the top
priority of the "maintainer duties", doing other stuff only when I feel
some exceptional urge to do so. Since the patch queue seems to never get
empty (I'm still having hopes that this will eventually change...), that
means that I don't do much general bug fixing outside the freeze
periods. So, the freeze period works as a tool for getting at least some
bug fixing done. I could organize my activities in some other way too,
but I probably won't (I really think that patch review is the most
important maintainer duty, so if I did some changes to how I work, I'd
probably cut down the bug fixing activities even further).

I'm not sure how to tie this rambling to your text... Your suggestion
sounds pretty good. There are (at least theoretical) cases where it
doesn't make sense to commit to any arbitrary time limit, but those
cases are very rare.

> 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?

Maybe I'm strange, but I think a moderate amount of regular meetings
might actually make contributing more fun.

-- 
Tanu