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

[Aaron Griffin]

On Fri, May 7, 2010 at 11:44 AM, Pierre Schmitz <pierre at archlinux.de> wrote:
> 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
> problem
> 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
> day.
>
> proposal for [testing]
> * never push any known-to-be-broken packages here (for example incomplete
>  rebuilds)
> * 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?

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).

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...)