Proposal for a JavaLibraryFreeze
Thierry Carrez
thierry.carrez at ubuntu.com
Wed Nov 3 12:28:11 GMT 2010
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.
--
Thierry Carrez
Ubuntu server team
More information about the ubuntu-devel
mailing list