Proposal for a JavaLibraryFreeze

[James Page]

On Wed, 2010-11-03 at 11:37 +0000, Dave Walker wrote:
> I entirely agree that *something* needs to be done.  Having been a 
> victim of dependencies changing from under me, sometimes in a cascade, 
> with my work on Eucalyptus last cycle - I wasted significant time trying 
> to locate the issue, and also wasted valuable upstream time to help 
> create a resolution.
> 
> Currently, we don't have a notion of RFC'ing when developers want to 
> modify (mainly sync / merge), and heavily relies upon interested parties 
> being fortunate enough to 'see' the bug, before some pain is inflicted.  
> One example of this was Bug #614981 [0].  This system, in my mind, 
> doesn't scale.
> 
> I would really like to hear James Page's thoughts on this subject, as he 
> is undertaking some significant Java work this cycle in the server area.

I think that pushing a JavaLibraryFreeze as close as possible to the
DebianImportFreeze makes alot of sense as it gives a clear period of
stability prior to FeatureFreeze to ensure that dependent stacks can
resolve any integration/library issues that new versions of Java
libraries may cause;  as Dave points out late sync's from Debian in the
Maverick cycle caused a-lot of pain which could potentially have been
avoided by taking this approach.

We should then take a FFe style approach post JavaLibraryFreeze to
ensure that any bugs/syncs/merge activity do not have significant impact
on dependent stacks; here's a starter for ten on when to reject a Java
Library update post this freeze point:

1) major version upgrade e.g. version 1.0.18 -> 2.0.xx
        Should give some stability (but not guaranteed) for API
        compatibility.

2) introduction of new dependencies implying new features
        Reduces the risk that a main Java library starts pulling in
        universe dependencies which would required MIR's; we had
        examples of this in Maverick (see [1]) which where patched out
        due to potential impact and lack of time.
        
3) potential for impact on key stacks such as Eucalyptus/UEC
        Dave's referenced bug [0] is a good example where this was
        picked up pro-actively and blocked for Maverick.

Some of these issues should be resolvable by having a specific focus
prior to the DebianImportFreeze (and JavaLibraryFreeze) on ensuring that
the key Java dependencies for core stacks are in a good state in terms
of upgrades/MIR's which should reduce the potential for having to go
through a JavaLibraryFreeze exception.

As my specific focus in Ubuntu is on Java libraries and stacks I'm happy
to pick-up coordination of this pre-freeze activity and act as a point
of reference for any freeze exceptions in terms of impact assessment
etc.

        
[0] https://bugs.launchpad.net/bugs/614981
[1] https://bugs.launchpad.net/bugs/552613

-- 
James Page
Software Engineer, Ubuntu Server Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20101103/b12627e0/attachment.pgp