On 06/29/2012 06:43 PM, Tanu Kaskinen wrote:
> 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.
But I'm not claiming it's false either :-)
>> 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.
I'm just thinking it's probably more complicated. E g, in a 6-month
cycle a bug introduced in month 1 might be discovered during development
in month 4, where it would have been otherwise caught during the test cycle.
>>> 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.
There are people doing that, otherwise there would be no use pushing the
tarballs if nobody was using them :-)
I'm thinking people like Liam or Feng Wei would like to test that we
don't break UCM for a release candidate.
> 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?
It's the other way around actually. In that scenario, I would definitely
push 4.0 to Ubuntu 13.04 because that would mean that there was plenty
of time to test and sort out bugs from 4.0, which I could then commit
upstream for either 4.1 or 5.0. Then I would be anxious about whether to
actually push 5.0 or stick with 4.x for the release.
>>> 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.
Okay.
As another example for aligning with things; I just pushed a patch that
will start to have effect with kernel 3.6 (the Phantom jacks). Had we
aligned with a specific kernel release, I would know whether it would
had made sense to push it now, or whether to wait.
>> 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...
If we have a 4 months cycle, I would say 1 months freeze is slightly too
little, I'd lean towards 1,5 - 2 months of freeze to be optimal.
Possibly with a -next branch in order not to block things for the next
release.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
