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
signature.asc
Description: This is a digitally signed message part
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
