On 06/09/2012 08:26 AM, Tanu Kaskinen wrote: > 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. Especially as I don't remember being part of that private discussion, and did not know it had existed. > 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. Certainly. >> 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. Okay. I appreciate your honesty about it. Personally, I do PulseAudio development/bug fixing/discussion/etc almost exclusively as part of my work day. As such; I feel partially responsible that Ubuntu has the best sound stack possible (in absolute terms, rather than compared to other distros), and part of that is making sure PulseAudio is great in terms of both quality and features. > If we had 3-month cycles, the amount of work needed to polish a release > should be smaller, I'm not sure that this is correct. I guess it is also depending on the "what is a release critical bug" question. > 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. True - but if we end up spending less time testing the every release as a result of releasing more often, would that cause quality to suffer? Or would it lead to more frequent checkpoints; causing errors to be caught earlier? Hard to tell. >> 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. The question is quite relevant IMO. When Lennart ruled the project, I believe the mission was to do just that (for Fedora). And even if we don't target a specific distribution these days, we still have Gnome and KDE releasing on 6-month schedules. On the other side we have Linux, which releases every 2-3 months. Are there more upstream projects that could be beneficial to align with, to make it easier for *any* distribution to get a consistent stack? > I don't mind discussing the mission and vision, it might very well be > beneficial, but maybe it should have its own thread? Sounds reasonable. Finally, I don't want to throw Ubuntu's release cycle in your faces and say "here, follow this or else", I hope nobody took it as that, and I can (and have to) live with whatever we come up with. What would work best for me would be hard release dates, and I can only say that it has been working out well for Ubuntu as well. Semi-hard would work as well; where the release can float a week or two depending on bugs etc, but requires a track record of us being able to live up to that. Currently, our track record of having months of delay between scheduled release and actual release, which makes planning difficult. :-( When possible, I try to pick work tasks for myself that will benefit both upstream PulseAudio and my distribution, so e g, as I currently do not know if the autumn's version of Ubuntu will use 2.x or 3.x of PulseAudio, it's difficult to know if it's worth putting together a 2.1 release or not. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
