Secondary ARCH

Dennis Gilmore dennis at ausil.us
Mon Mar 5 19:50:18 UTC 2007


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?

> * 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. 

> 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

> * How do we make it easy for patches to flow in, although this problem
> with one SCM that's external.  Although there's then a need for a policy
> around how to give commit access or not



-- 
Dennis Gilmore, RHCE




More information about the fedora-advisory-board mailing list