[pulseaudio-discuss] 3.0 release schedule
david.henningsson at canonical.com
Tue Jun 5 02:52:48 PDT 2012
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).
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
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
Ubuntu (and derivatives) and Fedora release in 6-months cycles,
originally because GNOME does that , 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 , 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
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.
More information about the pulseaudio-discuss