[pulseaudio-discuss] 3.0 release schedule

[David Henningsson]

On 06/05/2012 09:51 AM, Tanu Kaskinen wrote:
> Hi all,
>
> I'd like to get a consensus on the 3.0 schedule.

Thanks for bringing it up.

> We have not yet agreed
> on the freeze and release dates. There has been some discussion in the
> irc, and I'll summarize that here as far as I can remember it:
>
> I have suggested a freeze date of June 26th. When planning the 2.0
> release, we agreed to try the time-based release model with four-month
> cycles. June 26th is exactly four months after the 2.0 freeze. My
> suggestion for the release date is "as soon as we have no release
> blocker bugs and the latest release candidate has been out for long
> enough". That is, ASAP without any fixed target date. This model can be
> described as "releases happen every four months, on average".
>
> Arun has suggested a release date of September 11th, and freeze a month
> prior to that (so August 11th would presumably then be it). September
> 11th is exactly four months after the actual release date of 2.0. This
> model can be described as "the time between each release is at least
> four months".
>
> David has asked which model would require the least work.
>
> I don't remember if Colin has said anything on the matter.
>
> My opinion is that deciding the release date is meaningless, because the
> release will anyway get done when 1) the code is in releasable state and
> 2) the maintainers have time to do the release routine. A deadline date
> can maybe help with motivation a bit, but that's it. There's nothing
> enforcing a strict deadline anyway. I don't mind people setting targets
> for themselves, of course, but my target will be "ASAP" in any case.
>
> As for David's question - I don't see any significant difference in the
> required work between the two suggested models. In either case all
> critical bugs have to be fixed - they won't disappear just by waiting a
> little longer. I imagine rolling the tarballs requires only little work
> in comparison (I have never done that myself, so I might be wrong).
>
> Opinions?

Of course we have :-)

The tl;dr version: My suggestion is 6-month cycles with hard release dates.

Coming from the distribution side of all this. The distributions are our 
biggest consumers: Ubuntu and Fedora both release on a relatively fixed 
schedule, Debian's schedule is less fixed. Arch is rolling release. (I 
don't know how Mageia, openSUSE and Gentoo works in term of releases and 
flexibility.)
Of course the mobile space are big consumers as well, but I know little 
about them and how they use PulseAudio, except possibly "take a really 
old version and never update it" ;-) Feel free to enlighten me if I got 
that wrong.

Ubuntu (and derivatives) and Fedora release in 6-months cycles, 
originally because GNOME does that [1], IIRC. I think it would make 
sense for us to do the same. Gnome freezes in Aug/Feb and releases in 
Sep/Mar. Us being a little more of a critical infrastructure and 
hardware dependent package than Gnome (i e requiring a more diverse 
testing), a freeze in Jul/Jan and release in Aug/Feb would probably be 
even better. Possibly with bug-fix/stable release the month thereafter.
For the record, KDE also releases twice a year, latest two releases were 
in Jan and Aug [2], so if we want to align to that we should move 
backwards a month or two.

The harder our freezes, the more I can rely on our time plans, the 
easier for me, and IMO, the better for PulseAudio: As an example, assume 
we freeze in July. If I know that we will release in August, and that 
all of us will work to make that a stable release, I could push that 
release candidate to Ubuntu for some extra testing, which I believe 
would be very beneficial to PulseAudio's quality.
But if I'm unsure whether our release candidate will just lie there for 
two months, and then a new candidate will be pushed and so forth, I 
can't push it into Ubuntu. So far, unfortunately, we've leaned towards 
the latter, with release dates moving forward. Are we able to devote the 
time necessary to do the former? It doesn't take more time, but it 
requires more discipline to devote the time when it's necessary.

Somewhat related to this discussion, there could be two parallel 
discussions:

  1) When are we release-ready, and how do we decide which bugs are 
release critical? In Ubuntu I have far more bugs for PulseAudio than I 
could ever process myself. And if "at least no known crashers" is one 
criteria, that makes me scared of pushing crash bugs from Ubuntu 
upstream if that could defer our schedule. Such a policy, while I 
understand the reasons for it, would quickly change us from being 
release-when-ready to release-when-obsolete. (That is, unless money 
happens to fall from the sky and we can employ a lot of people to make 
sure they are fixed, or something.)

  2) What is PulseAudio's long term goals and visions? Right now, if 
feels like we all work in our own little areas - I do jack detection, 
Arun does echo cancelling, and so on. I'm not saying that is the worst 
of scenarios, but if we could work on unifying our views of what 
PulseAudio should be, we could then figure out if our release schedule 
contributes to that vision or not. Talking about goals and visions 
sounds awfully manager-ish (especially if it means coming up with catchy 
phrases!) but sometimes it could make sense to take a step back and see 
what we have in common, and what we want to work for.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[1] https://live.gnome.org/ReleasePlanning
[2] http://techbase.kde.org/Schedules