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. >
Sorry that I missed the discussion at UDS, as this sounds pretty important. Should we instead simply make the manual sync review process a bit more stringent for libraries? If a library introduces a new upstream version or new dependencies, and has rdepends that are not mentioned in the sync request, those rdepends should be added to sync request bug tasks with a Critical status, and then would need to be closed (Fix Released or Invalid) before the sync is done. Closing them means testing the rdepend with the new version. A process could be built to just do rebuilds of rdepends automatically before sync, and just add the FTBFS as tasks. Also component-mismatches logic could be used to submit the MIR-needing-bits as bug tasks. In this way, if a sync request would break the release, we can catch it before it happens. This eliminates need for a freeze, and just puts restrictions on syncing big libraries after DIF. -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
