Clarifying Feature Freeze Definition

[Colin Watson]

On Fri, Aug 05, 2011 at 05:14:04PM -0400, Scott Kitterman wrote:
> On Friday, August 05, 2011 03:50:22 PM Kate Stewart wrote:
> > Reviewing my notes from Natty,  the other area that would be good to get
> > input on is what is the last cutoff point for a compiler/interpretter
> > toolchain (gcc, eglibc, binutils or python, java, etc.) bug fix.   We
> > had a bit of churn and angst from that in Natty.  Is it reasonable to
> > make sure any bug fix for the toolchain packages goes through a FFE
> > after beta 1?
> 
> I think after FF.  That doesn't mean that there won't be FFes and they won't 
> get approved, but part of what I would want to see in such a request is an 
> estimated impact (e.g. 50 no change packag uploads) and identification of the 
> engineering resources to do that work (for all of the archive - particularly 
> after FF I think it's imperative that anyone trying to drive change into the 
> release own all the work associated with effects and related collateral 
> damage).

I would also say that this goes for any case where a change requires a
significant number of collateral-effect uploads.  It would be better,
IMO, to phrase things that way rather than singling out the toolchain.

Late toolchain fixes will typically be to fix things that are causing
real problems (ICEs, code generation problems, etc.), and then just
retrying the failures.  We don't particularly benefit from making that
harder, and I'm not sure that any of the release team are more qualified
to assess the likely effects of a change than the people uploading the
toolchain.  We are qualified to assess whether a significant number of
knock-on uploads might cause a problem, though.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]