Proposal for a JavaLibraryFreeze

[Scott Kitterman]

On Thursday, November 04, 2010 01:59:42 pm Kate Stewart wrote:
> 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?

What we are discussing here is, I think, broadening the traditional definition 
of toolchain.  Matthias is the best one to discuss what it has traditionally 
included, but higher level language interpreters (e.g. Python and Java) have 
not been a traditional part of the definition (Python 2.6 became a supported 
version just before feature freeze in the release when it was introduced).

I feel less strongly about Java, but for Python, I believe that transitions 
are long and complex enough that they should start at the beginning of the 
release cycle and not near feature freeze.  Fortunately Python 2.7 is the last 
Python transition and there is some hope that Python 3 transitions will be 
less painful (but I believe it's premature to base our planning on that).

A few cycles ago I started looking at Boost versions and making sure we had 
agreement on default Boost early in the cycle (ideally when the archive 
opened).  This helped us a lot with getting the transitions done (it's not 
just more time, if things are ready when autosync starts then a lot of 
transition work naturally happens when packages are built after sync).

Scott K