On Tue, 2012-06-05 at 11:52 +0200, David Henningsson wrote: > The tl;dr version: My suggestion is 6-month cycles with hard release dates. My initial reaction was that "come on, we already agreed to use 4 months", but then I remember that the "agreement" was done in a private discussion. So, reopening the cycle length discussion is OK. My opinion is that the shorter, the better (to a limit, of course, but e.g. 2 months would be fine to me). But more important than the cycle length is that we have time-based instead of feature-based release model, so I had no trouble of settling with 4 months in the previous discussion. I could easily live with 6 months too. > 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.) Rolling release users might like more frequent releases. > 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. That's what happened with Nokia's Maemo 6, which was rebranded as Meego 1.2 Harmattan (the "real" Meego used a sligthly newer version), but I'd hope that it's not that bad everywhere... I think Maemo 5 had pretty fresh PulseAudio at the time of release. > 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. Speaking for myself, I don't think I have the required discipline. I'm good at making plans about how to spend my free time, but I'm pretty bad at following those plans. If we had 3-month cycles, the amount of work needed to polish a release should be smaller, so the delays should be shorter too, and even in case of a badly delayed release, you'd get newer PulseAudio version in Ubuntu than with a badly delayed 6-month cycle. > 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? So far there hasn't been any formal criteria for blocker bugs. > 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.) If a policy causes unreasonable delays, it's a bad policy. But as I said, we haven't had any policy so far. > 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. I don't really see how the mission could affect the release schedule, unless the mission is something like "contribute to distibution X's success by fulfilling all of its sound server needs". If the mission is to cater to some specific distribution, then it of course makes sense to align as well as possible to that distribution's schedule, but I don't think anyone is suggesting such mission. I don't mind discussing the mission and vision, it might very well be beneficial, but maybe it should have its own thread? -- Tanu
