[arch-dev-public] Redefining [testing] and a new [staging] repo

Eric Bélanger snowmaniscool at gmail.com
Sun May 9 13:48:10 EDT 2010

On Sun, May 9, 2010 at 6:09 AM, Pierre Schmitz <pierre at archlinux.de> wrote:
> The biggest issue about this idea seems to be my bad description. ;-) So
> please ask questions and I'll try to make my point a little more obvious.
> I was asked if this concept would delay the release of new packages. The
> answer is of course not. It would even speed things up due to easier
> collaboration between devs. And if due to this new work flow more people
> would use testing we'll also get more feedback and could move packages
> sooner to core/extra.
> On Sun, 09 May 2010 16:49:55 +1000, Allan McRae <allan at archlinux.org>
> wrote:
>> So, things like the kde-unstable, gnome-unstable, xorg18 repos should go
>> in [staging]?  Or should they go straight into [testing]?   Because
>> people actually use them so [staging] may be too polluted for them, but
>> they are not ready for [testing]...  do we need another repo in-between?
>> :P
> No, you got me wrong here. The staging repo will only include packages
> that could be moved to core/extra or testing later. Those *-unstable repos
> contain beta versions that will never be pushed into any other repo. So
> those special repos could still be used and wont be affected.
> My goal was to have more people using testing. We could only achieve this
> if we make this repo more reliable. The main problem are incomplete
> rebuilds and those should be assembled in staging. So, most of the time
> staging will probably empty and packages that will be pushed there will
> stay for a quite short time. And there is no active testing or even
> sign-offs needed to move them to another repo.
> An example: Let's say I build openssl 1.0.1 with a so name bump. I wont
> have to rebuild at least core packages and no warning to not use testing
> atm has to be issued. I would just say "Hey, I just put new openssl into
> staging; please help rebuilding". Once we finished our rebuild list all
> those packages should be moved to testing and we can actually start using
> them.
> Using this approach the testing repo will never be inconsistent and more
> people could use it without the need to watch arch-dev-public for warnings.
> Of course this doesn't mean there wont be broken packages in testing; it
> just means that we don'T break things intentionally any more.

I like this idea.  It will be easier to collaborate on rebuilds.  And
you would only  to add the staging repository once  to your chroot
instead of adding/removing a repository for every rebuild (e.g. jpng).

>> How about we just make the group owner of the root of repo to allow
>> people with push access to [core] to create repos and have db-scripts
>> only fail if [community{,-testing}] is used on gerolde?
> That's probably something we want to do anyway. But it's not the solution
> to this problem here. I don't believe anybody will create a new repo for
> just a couple of rebuilds, adjust their pacman.conf etc.. They will just
> keep pushing unfinished rebuilds straight to testing. That's why I think
> this step needs to be made easy and without any overhead.
> --
> Pierre Schmitz, https://users.archlinux.de/~pierre

More information about the arch-dev-public mailing list