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 -- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
