proposed-migration blocks for milestones

[Scott Kitterman]

On Thursday, September 05, 2013 20:31:19 Steve Langasek wrote:
> Hi Scott,
> 
> On Thu, Sep 05, 2013 at 06:25:28PM -0400, Scott Kitterman wrote:
> > > 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.
> > 
> > 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.
> 
> Having packages frozen in -proposed still negatively impacts velocity,
> because nothing in -proposed is being used by the developers and other
> users; a full development iteration means the changes need to reach the
> release pocket, where they can be used by developers and other users,
> incorporated into images, and subjected to additional image-based
> integration testing.
> 
> It certainly helps to be able to upload to -proposed instead of not being
> able to upload at all, but the milestone freeze does still slow down
> development.  And in this context, I think it's an unnecessary slowdown.

Perhaps.  For those packages that are part of the CI environment, it might 
make sense to whitelist them from the block process.  I think this won't be a 
problem again until the Alpha series for "T", so there is some time to 
determine which packages or the criteria for selction to be exempt.

At the very least, I think there should be some agreement among the affected 
products about the relevant package list.

This is probably a good topic to flesh out at the next UDS.

Scott K