The biggest issue about this idea seems to be my bad description. ;-) So please ask questions and I'll try to make my point a little more obvious. I was asked if this concept would delay the release of new packages. The answer is of course not. It would even speed things up due to easier collaboration between devs. And if due to this new work flow more people would use testing we'll also get more feedback and could move packages sooner to core/extra. On Sun, 09 May 2010 16:49:55 +1000, Allan McRae <allan@archlinux.org> wrote:
So, things like the kde-unstable, gnome-unstable, xorg18 repos should go
in [staging]? Or should they go straight into [testing]? Because people actually use them so [staging] may be too polluted for them, but they are not ready for [testing]... do we need another repo in-between?
:P
No, you got me wrong here. The staging repo will only include packages that could be moved to core/extra or testing later. Those *-unstable repos contain beta versions that will never be pushed into any other repo. So those special repos could still be used and wont be affected. My goal was to have more people using testing. We could only achieve this if we make this repo more reliable. The main problem are incomplete rebuilds and those should be assembled in staging. So, most of the time staging will probably empty and packages that will be pushed there will stay for a quite short time. And there is no active testing or even sign-offs needed to move them to another repo. An example: Let's say I build openssl 1.0.1 with a so name bump. I wont have to rebuild at least core packages and no warning to not use testing atm has to be issued. I would just say "Hey, I just put new openssl into staging; please help rebuilding". Once we finished our rebuild list all those packages should be moved to testing and we can actually start using them. Using this approach the testing repo will never be inconsistent and more people could use it without the need to watch arch-dev-public for warnings. Of course this doesn't mean there wont be broken packages in testing; it just means that we don'T break things intentionally any more.
How about we just make the group owner of the root of repo to allow people with push access to [core] to create repos and have db-scripts only fail if [community{,-testing}] is used on gerolde?
That's probably something we want to do anyway. But it's not the solution to this problem here. I don't believe anybody will create a new repo for just a couple of rebuilds, adjust their pacman.conf etc.. They will just keep pushing unfinished rebuilds straight to testing. That's why I think this step needs to be made easy and without any overhead. -- Pierre Schmitz, https://users.archlinux.de/~pierre