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 [email protected] 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 ;) -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
