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
