On Thursday, October 28, 2010 04:47:37 pm Thierry Carrez wrote: > A few hours ago, during the UDS "Java Library Housekeeping" session, we > discussed the damage that was done during the Lucid and Maverick cycles > by introducing new versions of Java libraries late in the cycle. > > The problem is that our main Java stacks, and in particular Eucalyptus, > can break quite late in the cycle when one of those libraries in synced > or merged from Debian. Lots of these seemingly innocent library updates > introduce API breaks which require some significant amount of adaptation > on the library-using software. In some other cases, it introduces new > dependencies, which usually push the package in component-mismatches and > require triggering dozens of MIRs (by virtue of the Java dependency > hell). This is acceptable at the beginning of the cycle, but later in > the cycle it's a lot of pain for questionable benefits.
Were these violations of feature freeze or might they have been if we had a better definition of feature? > So we would like to introduce the idea that Java libraries should not be > merged or synced after a date called JavaLibraryFreeze, unless there is > a compelling reason to do so (i.e. something we have packaged requires > the new version). This JavaLibraryFreeze must obviously occur at the > same date or shortly after DebianImportFreeze. I'd suggest that both are > on the same date, but maybe that's a bit too extreme. Can we just wrap this up in feature freeze somehow? It's not that long after DIF. Scott K -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
