Proposal for a JavaLibraryFreeze

[Kate Stewart]

On Thu, 2010-11-04 at 13:27 -0400, Scott Kitterman wrote:
> On Thursday, November 04, 2010 12:08:02 pm Robbie Williamson wrote:
> > On Thu, 2010-11-04 at 10:29 -0500, Robbie Williamson wrote:
> > > What if we had a ToolchainFreeze, that covered GCC, Java Libraries,
> > > and
> > > Python...as changing any one of the 3 late in cycle can lead to
> > > extreme
> > > pain and suffering?
> > 
> > Given how adding more freezes is suboptimal, another option is to roll
> > these into the DIF, and have it stand for
> > DistroInfrastructureFreeze...or something like that.
> > 
> For Python, I think that's not a bad time to be making the final decision about 
> what version is default, but I think for introducing new supported versions, 
> it's far too late.  I think new Python (and in the future, Python3) versions 
> should should be introduce with or at the latest shortly after the toolchain 
> for the release (which is what we've done this cycle with Python 2.7).

Getting any infrastructure packages (ie. those with extensive dependency
chains) as early in the cycle as possible, makes sense.  gnu toolchain,
Java libraries, Python are all logical candidates.   are there others? 

Possibly the term "freeze" is causing some semantic confusion, since we
would want to be able to fix bugs (which are likely to be surfaced from
the dependency chains).   Does  DistroInfrastructureAvailable capture
the notion that the default infrastructure packages have been uploaded,
and should start to be exercised and find any issues with the
dependencies?   

- Kate