On Fri, May 7, 2010 at 12:12 PM, Ray Kohler <ataraxia937@xxxxxxxxx> wrote: > On Fri, May 7, 2010 at 12:44 PM, Pierre Schmitz <pierre@xxxxxxxxxxxx> 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
