Proposal for a JavaLibraryFreeze

[Scott Kitterman]

On Wednesday, November 03, 2010 08:28:11 am Thierry Carrez wrote:
> Scott Kitterman wrote:
> > 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?
> 
> IIRC some of them were, some of them weren't.
> 
> >> 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.
> 
> I don't think that would protect us well enough. Some of those
> sync/merges happened around FeatureFreeze time, and adapting Eucalyptus
> for an upgrade in GWT is a non-trivial task that could be seen in itself
> as requiring an FFe... What we generally did to fix it is to revert the
> sync/merge using some 2.1butreally2.0 ugly versioning.

I'd rather see if we can solve this problem by specifying target versions in a 
spec and then getting people to stick to the plan.  We used to have quite a 
variety of freezes and we consolidated them because they were causing 
confusion.  Making another type of freeze is something we could do, but I'd 
rather leave that as the last option.

Could someone write up a plan for what libraries we should be aiming for for 
Natty?

Scott K