proposed-migration blocks for milestones

[Steve Langasek]

Hi all,

So you can blame me for instigating this thread, since I was complaining at
Laney on IRC about package uploads getting caught up in the long freeze for
beta-1.

On Wed, Sep 04, 2013 at 04:41:21PM +0100, Iain Lane wrote:
> This cycle we've been blocking packages from migrating between
> saucy-proposed and saucy when milestone freezes have been going on. The
> first time I think Scott K manually generated a list of packages
> somehow, but after that I wrote a script that blocks everything on a
> flavour's images based on this being the most obvious and conservative
> thing to do.

> I think this is proving to be too heavyweight. Notably, it ends up
> blocking large parts of the base system.

> Let's come up with some new rules. Here are some initial ideas.

>   * (For alphas?) Don't block by default. If you want one, you have to
>     explicitly ask for it.
>   * You don't get to block packages for flavours not participating in
>     the milestone. That is, the block will be the union of the packages
>     on images of flavours participating minus the union of the packages
>     on images of flavours not participating.

> Also, having this beta freeze at a week feels a bit long. Perhaps it
> should start on the Monday of Beta 1 week instead.

The goals that I see need to be balanced for the freezes of the opt-in
milestones are:

 - flavors preparing a milestone should not have their work disrupted by
   people working on other flavors
 - people working on flavors that are not participating in the milestone
   should not have their work slowed down by flavors that are participating
   in an opt-in milestone.

We obviously can't satisfy these goals for both groups 100% of the time,
which is why I say they need to be balanced.  But I think we can do better
than the current situation, which is currently too conservative about
disrupting those flavors opting in.  This is not only bad for the flavors
not participating in the milestone, it's also to the detriment of those
flavors that *are* participating if it means their developers have to go
through an extra process to get their milestone-critical fixes landed.

The original motivation for the long freezes, AIUI, was twofold: to reduce
the risk of regression caused by uncoordinated changes to packages going
into the milestone, and to get a consistent archive so that milestone
candidate images could be spun when needed without too much back-and-forth. 
The first point may still be a problem.  But for the second point, as Martin
writes:

On Wed, Sep 04, 2013 at 07:03:08PM +0200, Martin Pitt wrote:
> Freezing a week before was still appropriate in the days where the
> release team had to spend Fri, Mon, and Tue to fix uninstallable
> packages, component mismatches, and grave installer bugs. Now that we
> have these mostly covered by our CI testing, my feeling is that
> freezing on Monday or even Tuesday should be fine. We should still
> test the previous Friday's daily manually to verify that we didn't get
> any installer bugs that aren't covered by the automatic tests, of
> course, but I don't see a need to freeze at the same point any more.

We are in a very different place wrt archive quality than we were two years
ago, and I think it's important that our milestone freeze processes adapt to
reflect this.

So I agree with Martin and Scott that we should be freezing Monday (for
betas) or Tuesday (for alphas) of the milestone.  Some freeze is still
warranted, but it doesn't make sense for the freeze to be as long as it has
been in the past.

And to be clear, I think this freeze reasoning applies to the final beta as
much as it does to the opt-in milestones.  If anything, a long freeze should
be *less* necessary for final beta coming as it does post-FF; I think we
need to be more concerned about making sure we're driving -proposed down to
zero for the beta so that we get a milestone that gives us as good a picture
of the final release as it can, instead of trying to freeze and artificially
control what's going into the beta.

I would therefore propose that we freeze for Final Beta on Monday, September
23 instead of on Thursday, September 19.  The UIFreeze and
DocumentationStringFreeze would remain the same.

Does this sound reasonable to everyone?


Finally, there's one other point that I think we should discuss regarding
the opt-in freezes.  The current model for opt-in milestones is that we
freeze all those packages which are used by any of the opting flavors.  I
don't think this is in the spirit of the original compromise that was
proposed, however - particularly since two of the flavors that have been
doing opt-in milestones, UbuntuKylin and Edubuntu, are deriving directly
from the ubuntu desktop seed, with the result that for beta-1, all of Ubuntu
Desktop was frozen.  I don't think this is a reasonable outcome; the Ubuntu
Desktop team are explicitly *not* participating in these milestones in order
to maintain development velocity, and it's not fair to them to have flavors
that are "downstream" of them imposing a freeze on their work.

I think it's fine for Edubuntu and UbuntuKylin to participate in the opt-in
milestones, but we shouldn't freeze the Ubuntu Desktop packages for this.
They can choose to freeze the packages that are part of their overlay, but
where the Ubuntu Desktop packages are concerned, there should be a level of
trust in the CI methodologies that we have put in place for the Ubuntu
Desktop itself, instead of freezes whose effect is to reduce alignment
between Ubuntu and the other flavors.

Thoughts?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20130905/af7db248/attachment.pgp>