Secondary ARCH

[Dennis Gilmore]

On Monday 05 March 2007 01:54:26 pm Jeremy Katz wrote:
> 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.

It does to the extent that we would only have one copy not the three we 
currently keep.my understanding of how the primary mirror is setup is that 
there are three sites currently. 

> > > * 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.
these could be created close to the master buildsys and downloaded for 
testing. 

> > > 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.
I was told that its possible awhile ago when i asked if all sparc extras bugs 
got assigned to me.  I was told i could be cc'd but not made the owner based 
on arch.  I'm asking now to make sure that we can indeed do that.

-- 
Dennis Gilmore, RHCE