Clarifying Feature Freeze Definition

[Scott Kitterman]

On Friday, August 05, 2011 12:17:22 PM Kate Stewart wrote:
> Dear Release Team members, and others interested,
> 
>    In asking around and after reading the documentation I'm hearing some
> varied opinions of what it actually means to feature freeze.  On reading
> https://wiki.ubuntu.com/FeatureFreeze,  it seems to not be as specific
> as needed.
> 
> "At this point we stop introducing new features, packages, and APIs, and
> concentrate on fixing bugs in the development release."
> 
> My expectation is that the freeze is for all main packages, and seeded
> universe packages.

As Micah mentioned, this has applied to the entire archive.  We've gone 
through iterations with different Main/Universe freezes and separate freezes 
for New versions/New packages/New features and after much experimentation 
concluded that one "Feature Freeze" was the least confusing approach.

> In WIKI it states:  "For the purpose of the FeatureFreeze, the upload
> date matters, i. e. all packages which are in the NEW queue by that time
> will be processed without the need for an exception."
> 
> So my question areas are:
> 
> 1)  Is everyone comfortable with this comfortable with using upload date
> and NEW queue?   How long after it being in the NEW queue does it need
> to be processed by?   I think we need to aim for them all to be
> processed within the week, but would like to hear what's reasonable from
> the AAs.

I wouldn't worry about it.  With limited exceptions, the ability of New 
pacakges to cause regressions in the archive is minimal.  The primary purpose 
of freezing New package acceptance is to reduce AA workload so the people 
tasked with this work have more time for other tasks as we get closer to 
release.  I also think that if something drags out a really long time and it 
gets to the point where it's problematic, AAs are experienced enough to know 
this and discuss it before accepting.  I don't think the release team needs to 
explicitly track this.

> 2) if a package is rejected just before FF due to a technicality,  does
> it need a FFE exception after?   What consititutes a technicality?

If something is in queue at FF and is rejected after FF due to a serious 
defect we have processed such packages when re-uploaded after FF without FFe.  
I think this is reasonable.  I think it's reasonable to process packages 
rejected shortly before FF the same way.   OTOH, is someone uploads 20 new 
packages the day before FF and most of them have to be rejected, I'm probably 
going to suggest they are too late and should wait for the next cycle and do a 
better job.  Once again, I don't think the release team needs to manage this 
very closely.  If there's a question/problem any AA can bring it to the 
release team.  IIRC, in the past, we've done FFe for packages rejected before 
FF, but it was really easy to get an FFe in that situation (as long as it was 
shortly after FF).

> 3) by feature freeze, all new images for the manifest should be building
> daily images?  (I consider a new hardware platform as a feature ;) ).

I think this makes sense.  Put slightly differently, any new images after FF 
would need an FFe from the release team.

> 4) anything else others have been finding unclear?

The only thing that I'm aware of (which I still totally don't understand how 
it was unclear) was last cycle someone thinking U/I changes didn't count as 
features.  If we haven't made it really clear that all feature changes need 
FFe and U/I Freeze is the time after which ALL U/I changes need review (not 
the feature deadline for U/I) then we need to.  I thought it was perfectly 
clear before, so I'm not the right person to judge if it's clear enough now.

> Would like to get some concensus,  and then broadcast this so the
> expectations are clear with the development community too.

I would caution you against trying to make the rules too specific.  They should 
be parameters to which people should apply judgement.  If you make them too 
specific, then people will start asking like rules lawyers and try to figure out 
a way to interpret the words to mean they can do what they want.

Scott K