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