On Fri, May 7, 2010 at 12:12 PM, Ray Kohler wrote:

On Fri, May 7, 2010 at 12:44 PM, Pierre Schmitz 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?

Even though I'm just a user, I'd like to add my support to this idea. I even considered proposing it myself less than a month ago. I run [testing], since I want to contribute to finding problems before they reach [core] and [extra], but I don't like having to deal with [testing] having rebuilds in it. I have never broken my systems by a bad package in [testing] but have unfortunately pulled incomplete rebuilds a few times now.

I guess the point of this post is to show that there is at least one user who cares enough about this idea to speak up for it. I suspect there are others who don't run [testing] now who would begin doing so if this plan were implemented.

this is slightly off topic, but i thought it was worth a mention. this is also the kind of assurance i wish to provide with tight BTRFS integration into Arch... i think the easier the user can recover from getting cut by "the bleeding edge", more people, maybe orders more, would be willing to permanently use [testing] packages. i presume the only thing stopping people now is the inability to easily revert/recover from anything without some degree of manual intervention. more time using/testing and less time swearing/sobbing :) C Anthony