Proposal for a JavaLibraryFreeze

[Robbie Williamson]

On Wed, 2010-11-03 at 13:36 +0000, James Page wrote: 
> 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
> 

What if we had a ToolchainFreeze, that covered GCC, Java Libraries, and
Python...as changing any one of the 3 late in cycle can lead to extreme
pain and suffering?

-- 
Robbie Williamson                                      robbie at canonical.com 
Canonical, Ltd.                                   robbiew[irc.freenode.net]                               

"You can't be lucky all the time, but you can be smart everyday" 
 -Mos Def

"Arrogance is thinking you are better than everyone else, while
Confidence is knowing no one else is better than you." -Me ;)