Plan for tomorrow's (20070604) Release Engineering meeting

[Nils Philippsen]

On Fri, 2007-06-08 at 01:32 +0200, Axel Thimm wrote:
> On Thu, Jun 07, 2007 at 11:18:46PM +0200, Nils Philippsen wrote:
> > On Mon, 2007-06-04 at 14:15 -0400, Jesse Keating wrote:
> > > On Monday 04 June 2007 13:45:07 Tom "spot" Callaway wrote:
> > > > I thought about this, but it wouldn't ensure proper ordering between
> > > > packages. Packager A rebuilds after Package B is done, but changes to
> > > > Package A affect Package B's build.
> > > 
> > > How would a mass rebuild be any different?  A mass rebuild is likely to go 
> > > through in either ls ordering or python hash ordering....
> > 
> > That needn't be the case. Packages could be built in a "from the ground
> > up" order beginning with what's by default in the buildroots (i.e. what
> > doesn't need to be build-required). This gets only ambiguous with cyclic
> > build-dependencies in which case we'd have to fall back to something
> > else (ls ordering, python hash ordering or even "bug the release
> > engineers and let them decide" ;-)).
> 
> But Jesse rightfully argues that doing so requires a createrepo
> running after each build [1], which takes 20-30 minutes. So for 4000
> packages you would need 55-83 *days* just for createrepo.

Only if you'd do a whole createrepo for each package built. Surely it
must be possible to take the existing repo metadata and just update them
with that of the newly built package and surely it wouldn't take so much
time, right?

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little
Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011