Proposal for a JavaLibraryFreeze

[Scott Kitterman]

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