Re: [arch-general] [arch-dev-public] Redefining [testing] and a new [staging] repo
On Fri, May 7, 2010 at 1:40 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
On Fri, 7 May 2010 12:13:33 -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
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.
Somehow yes, but the detail is quite important. But a already existing repo will make things a lot easier. Maybe its worth to manually create a separate repo but probably not for just a few. We also sometimes upload packages somewhere to share or let others grab them from our home dirs on gerolde. Such a repo would simplify this and induce a general work flow for e.g. rebuilds.
But still, the main intention is to make testing more usable to get more feedback and in turn have less bugs in core/extra.
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.
Sure, the implementation of this is a peace of cake: mostly a mkdir and maybe adding some shortcuts to devtools and dbscripts to have something like stagingpkg and staging2extra etc..
This makes me wonder, what about the TUs and [community-testing]? The current use of that repo would make it seem sensible to rename it to [community-staging] instead, since it's rare there's anything in there but in-progress rebuilds. Or should there be a pair of [community-testing] and [community-staging]? Sorry about adding complexity to this, as I realize that makes it less likely that it actually gets implemented...
On Fri, 7 May 2010 13:50:01 -0400, Ray Kohler <ataraxia937@gmail.com> wrote:
This makes me wonder, what about the TUs and [community-testing]? The current use of that repo would make it seem sensible to rename it to [community-staging] instead, since it's rare there's anything in there but in-progress rebuilds. Or should there be a pair of [community-testing] and [community-staging]?
Sorry about adding complexity to this, as I realize that makes it less likely that it actually gets implemented...
That's up to the TUs to decide if they want to have the same or keep their testing repo for this. I guess it wont be needed most of the time; most packages that would induce rebuilds should be in core and extra. But even if if they would like to have their own staging repo it would be easy to implement. -- Pierre Schmitz, https://users.archlinux.de/~pierre
participants (2)
-
Pierre Schmitz
-
Ray Kohler