Proposal for a JavaLibraryFreeze

[Thierry Carrez]

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.

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.

This would obviously be a soft freeze, so it doesn't prevent damage from
being done, but we hope to make it a bad practice and reduce the
problems we experienced over the last cycles.

Comments ?

-- 
Thierry Carrez
Ubuntu server team