On Fri, May 7, 2010 at 12:02 PM, Pierre Schmitz <[email protected]> wrote: > On Fri, 7 May 2010 11:50:11 -0500, Aaron Griffin <[email protected]> > wrote: >> I don't like it. It adds a lot of complexity. >> >> For large rebuilds, the dbscripts DO allow us to make on-the-fly >> repos, though currently the directory needs to be created by an admin >> (that can be changed). > > Having a repo for just this purpose will make things easier and I don't > see where it would increase complexity. > >> We've done this before with some releases, and I think it's a good >> idea to use this capability, rather than define a testing-testing repo >> (that's what this is - a testing repo before packages go to >> testing...) > > No you got me wrong here. It's not meant to be to test packages before > moving them to testing. Most packages will still be moved directly to extra > or testing. The staging repo would be just a place where we assemble larger > builds or could coordinate building with other devs without destroying a > real repo like testing. > > So, staging is no real repo, its not in a chain like > (staging->testing->extra) and our current work flow of directly putting > packages into testing or extra wouldn't be touched. > > I hope I made my point this time; though you are still allowed to dislike > it. :P
So in effect, it seems we're saying the same things, except I am using REPO_NAME="foo-rebuild" for each rebuild "foo", and you are using REPO_NAME="staging" for *all* rebuilds. This can already be done, the staging dir just needs to be added to the server. It would, however, need to be excluded from rsync if you want that.
