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

Pierre Schmitz pierre at archlinux.de
Fri May 7 12:44:22 EDT 2010

Hi all,

here is another crazy idea I was thinking about for some days. This should
improve our overall package quality and simplify our work flow. The
with out current [testing] repository are these:
* it is only used by very few people. Most of the times we don't get much
  feedback until packages are moved to core or extra
* it is often in a inconsistent state; especially during incomplete so
  name bump rebuilds
* sometimes packages are known to be broken or unstable

On the other side we are sometimes in need of some intermediate
repository. For example single people stack a pile of packages in their
home dirs until they can be moved to a repo at once. We have also seen
temporary repos like jpng to manage larger rebuilds.

My idea is to redefine the testing repo and introduce a new staging one.
(remember the good old days? ;-))
With the implementation of the package pooling moving packages between
repos can be done with nearly no overhead. So ideally
we should be able to use testing more often, even for a very short period
like a

proposal for [testing]
* never push any known-to-be-broken packages here (for example incomplete
* candidates for core are put here
* ideally new builds of important/critical packages or major rebuilds can
  be put here to test them by a larger audience.
* don't put any package in here which are never meant to be moved to
  core/extra. (like experimental alpha software etc.)

proposal for [staging]
* this repo should only used by devs and tus
* it is not meant to be used on a production system
* it should only be enabled in a packages build environment (chroot)
* this could be even excluded from outbound rsync. Due to package pooling
  packages would still be propagated. And moving those packages to other
  repos will be "instantly".

Summing things up more packages should be passed through testing, more
users should be able to use testing without breaking their systems and we
don't have to make them reading the high traffic arch-dev-public list. We
also should be able to collaborate more in packaging: Dev A puts a new lib
into [staging] and another one can start rebuild other packages using that
lib. Another common use case would be large builds like KDE we usually
start packaging one week before release. Till now those were put into
users' staging dirs and the other devs had to manually download them,
create a local repo and install them.

So, what do you think about this idea?



Pierre Schmitz, https://users.archlinux.de/~pierre

More information about the arch-dev-public mailing list