proposed-migration blocks for milestones

[Scott Kitterman]

On Thursday, September 05, 2013 13:50:45 Steve Langasek wrote:
> 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?

I guess a lot of that revolves around the question of how people feel about 
releasing install media with obsolete packages on them.  We've gotten more 
relaxed about that in recent cycles without any problems I'm aware of.  

OTOH, part of the reason for uploading to proposed was to allow teams to 
continue to work through these things.  I don't understand how two days of not 
migrating has any significant affect on development velocity.  AIUI, the benefit 
for non-participating flavors is that developers don't need to stop their 
normal work and test/fix issues associated with the milestone.  The larger 
effect on velocity comes from what people spend their time on and not on if a 
package migrates from -proposed or not.

Scott K