Fedora Board Recap 2007-NOV-13

Jesse Keating jkeating at redhat.com
Wed Nov 21 17:40:00 UTC 2007


On Wed, 21 Nov 2007 08:27:56 -0900
"Jeff Spaleta" <jspaleta at gmail.com> wrote:

> Both Jesse's idea of hardlinked archive and the srpm generation on
> demand will help here. But the hardlinked archive isn't going to scale
> out.
> 
> 2) Koji is space constrained. We are going to need to flush things
> from koji quite frequently. I'm not sure we can rely on koji to be the
> point at which we archive anything even srpms.  Nor do I think we have
> the resources to scale jesse's big pile of archived srpms.  His idea
> may scale just fine right now, but what happens a year from now when
> there are 12 different active spin SIGS, each producing monthly
> re-spins?  The space needed to house a hardlinked dump of all possible
> 'released' srpms is still an unbounded constraint.  The cvs and
> lookaside space on the other hand are consuming much smaller amounts
> of space currently and we can most certainly set a limit on the size
> limit for the re-generated srpms cache.
> 
> 3)re-generation of srpms on the fly lets us provide more than the
> absolute minimum in required service.  We should be aiming to provide
> source distribution for everything we've built through koji and has
> been in a publicly facing repository.. including rawhide.  The big
> ball of hardlinked srpms certainly can't give us source distribution
> coverage that also includes everything seen in the public rawhide
> tree.

I think the two efforts can go in tandem, however I would rely upon the
hardlinked tree as v2 3a distribution means, and not rely upon on the
fly generation to fulfill v2 3b/c.  Please avoid 3b/c at all costs.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20071121/a4b15fd9/attachment.sig>


More information about the fedora-advisory-board mailing list