Secondary ARCH

Jeremy Katz katzj at redhat.com
Mon Mar 5 19:54:26 UTC 2007


On Mon, 2007-03-05 at 13:50 -0600, Dennis Gilmore wrote:
> On Monday 05 March 2007 01:01:00 pm Jeremy Katz wrote:
> > On Mon, 2007-03-05 at 13:26 -0500, Christopher Blizzard wrote:
> > > What's needed other than a set of output rpms and isos?  From what I
> > > remember of the meeting we had a few months ago we expected secondary
> > > arch builds to happen on contributed machines, but wanted to host final
> > > bits.  That should be our target, right?
> >
> > I think the main technical things are (off the top of my head)
> > * Backend storage.  Probably fairly significant chunks as you're going
> > to want to keep releases (tree + ISOs), development (tree at least),
> > potentially test releases if they don't want/can't host themselves
> This is probably the biggest hurdle.
> 
> How long should we keep old releases around?  
> could we for instance move non supported realease to a single box and have it 
> available at archive.fedoraproject.org or even get rid of old releases 
> entirely at some point?

There are GPL requirements on keeping things around for a certain length
of time.  And for historical reasons, I don't think we ever want to get
rid of them entirely.  Not that I've had to go install Red Hat Linux 6.2
in a while, but it's nice that I _can_ if I need to :)  Something like
archive.fedoraproject.org probably could work, though, to help with
mirror burden.  It doesn't really help our storage concerns though.

> > * Sync mechanism.  We don't currently have a good way for these sorts of
> > things to get their bits onto above backend storage.  The "add an rsync
> > to an internal server that can run as a cronjob" really only gets us so
> > far.  I expect that the secondary arches would far prefer a push
> > mechanism.
> > * Need a good way to kick off the secondary arch builds.  This isn't the
> > highest priority, but it is eventually needed
> the sync and kicking off kinda come down to the same thing.  The way we have 
> briefly talked about doing this is to have a koji hub at the secondary arch 
> site and have it talk to the main hub.  which will do the queueing of builds 
> and sync things back to the main hub when built. 

Yes and no -- that helps for packages, it doesn't help for ISOs.  Or
live CDs.

> > Then, there are the more fuzzy things like
> > * How do we get bugs reported and ensure that arch groups find out about
> > bugs that are arch specific without adding much (if any) overhead for
> > everyone else.
> 
> have an alias for the secondary arch team or a mailing list.  and have all 
> bugs reported against that arch auto cc'd to the team

Yeah, that's the obvious answer.  Just have to make sure that we can do
it with bugzilla.

Jeremy




More information about the advisory-board mailing list