On Fri, May 7, 2010 at 11:44 AM, Pierre Schmitz <firstname.lastname@example.org> 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
> 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?
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