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.
