Proposal for a JavaLibraryFreeze

[Clint Byrum]

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.