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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
