[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
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?
Greetings,
Pierre
--
Pierre Schmitz, https://users.archlinux.de/~pierre
More information about the arch-dev-public
mailing list