On Mon, 2012-06-11 at 11:06 +0200, David Henningsson wrote:
> > 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.
What release tasks do you think there are that are not directly
proportinal in effort to the length of the release cycle? I don't see
how the release critical bug criteria question is relevant here: with
3-month cycles, the amount of blocker bugs per release should be half of
the amount of blocker bugs per release with 6-month cycles,
independently of what the criteria are for blocker bugs.
> > 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.
Getting changes faster to the general public will of course make the
bugs in those changes to become visible faster. As for diminished amount
of release candidate testing with more frequent releases: at least I
don't do any extra testing during release preparations, so more frequent
releases wouldn't impact my contribution to the testing. (To be clear, I
don't consider my contribution to testing to be zero: I always run a
development version of Pulesaudio on my computer, so the features that I
need in my limited personal use cases are continuously getting tested.)
Are there any people ("testers") who regularly run some test set on
release candidates? If there are such people, for them more frequent
releases would increase the workload, which might lead them to stop
doing what they are now doing. I'm not aware of any such people, but
maybe they just don't keep much noise about themselves.
Then there are distributions that might push the release candidates to
their users. I think these are the most valuable release candidate
testers. For the distribution maintainers, increasing the release
frequency would again increase the workload, possibly leading to them to
stop caring about the release candidates. I don't have any idea how
likely that scenario is. Your experience would be one data point: let's
say that the release cycle was 3 months, and PA 4.0 would be released
soon after Ubuntu 12.10, would you bother pushing the release candidates
for 4.0 to Ubuntu, knowing that 13.04 would probably end up using PA
5.0?
> > 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 myself see the point of explicitly aligning to Gnome or KDE or
anything else if they don't ask for it themselves. As long as you, as an
Ubuntu representative, remain the only person who has opinions about
PulseAudio release dates based on hard facts, I don't mind aligning to
Ubuntu at all. If other distributions start giving similar input, we can
then do a compromise between them and Ubuntu, until there are so many
conflicting wishes that a compromise becomes impossible and we can start
ignoring everybody.
> > 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.
No, I haven't seen any bad attitude from you :)
> 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. :-(
If you really think that hard release dates are useful, we can increase
the freeze length until we start reliably hitting the release dates. The
alternative is that you ignore our stated release date plan and make
your own guess about how long the process will take after the freeze
date. I'm not sure if there's a big difference, and either one is fine
for me...
The third alternative is that everybody promises to work harder to make
the freezes nice and short, and then meet those promises. But at least I
won't make any such promises.
--
Tanu
