[arch-dev-public] Redefining [testing] and a new [staging] repo

Pierre Schmitz pierre at archlinux.de
Sun May 9 06:09:45 EDT 2010


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 at 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


More information about the arch-dev-public mailing list