Testing Fedora - small (?) suggestion.

[Florian La Roche]

On Sun, Nov 12, 2006 at 10:41:56AM +0100, Nicolas Mailhot wrote:
> Le dimanche 12 novembre 2006 à 10:58 +1030, n0dalus a écrit :
> 
> > One way of dealing with this is to put the packages in the usual spot,
> > but modify createrepo to have an option to ignore packages that can't
> > be installed. Or just have a subdirectory containing the packages held
> > back (or even a repository).
> > 
> > So far I've mainly considered what to do if a new package requires
> > something that doesn't exist (or requires a higher version than is
> > currently provided). What should be done if the new package is
> > installable but causes other packages to become uninstallable? We
> > wouldn't usually want the new package to be held back in that case,
> > but I'm not sure what the best way to handle it is -- is it ok to just
> > (re)move the uninstallable package from the repository?
> 
> <handwaving mode="major"/>
> 
> Ideally the situation would be the following :
> 
> 1. developer A releases a set of packages breaking R or BR of packages
> of maintainers B, C, D
> 
> 2. buildsys detects the breakage, assigns a temporary repo to the broken
> packageset, warns A, B, C, D of the situation (maybe auto-opening
> bugzilla entries). Waits some standard period. Nags A, B, C, D every
> other day by mail.
> 
> 3. During the period fixed packages from B, C, and D are added to the
> temporary repo till it's complete. When it reaches completion it's
> merged with the main repo.
> 
> 4. if the breakage is not fixed by the timeout, send a mail to rel eng
> asking if they want to wait another period of proceed. If rel eng says
> wait, repeat. If rel eng says push, push to rawhide removing the
> packages broken as a side-effect (and mail the relevant fedora lists
> packages are being dropped ; probably auto-orphan them if they're not
> back by another period)
> 
> The only hard part may be to assign different temp repos to different
> broken packagesets, so maybe it'd be easier to work at the package
> level : 
> A. have a single staging repo,
> B. move every new build to this repo, and check at push time what
> packages can be safely moved to main
> C. assign TTLs to each individual package in this area
> 
> This would minimize the work of everyone and only escalate to rel eng
> when there is an actual problem
> 
> </handwaving>


Setting this up within a new tree that is adding in the rawhide
changes incrementally should also be possible. Then we can just
see how many people are happy with this setup and use it.

regards,

Florian La Roche