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 _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
