Secondary ARCH

Jeremy Katz katzj at redhat.com
Mon Mar 5 19:01:00 UTC 2007


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

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

Jeremy




More information about the fedora-advisory-board mailing list