On Fri, May 7, 2010 at 12:02 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
On Fri, 7 May 2010 11:50:11 -0500, Aaron Griffin <aaronmgriffin@gmail.com> 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.