[arch-dev-public] Testing policy
Time for the "big hat" We had some oopses today. Problems that were brought up less than 3 months ago, which reoccurred. In the past, Judd had a problem with saying that every package needs to go to testing. I don't. Going forward, every single [core] package MUST go to testing, and MUST be OKed by at least one other developer. The term here is "independent verification" - we want someone else, that is not you, to tell you this works. While we have no formal tools in place for this, eventually I'd like to have a way to "sign off" that a package in testing works. Just to clarify: This is not a request. This is not a discussion. The core repository is critical to ArchLinux systems and should never be broken like this. All core packages MUST go to testing and MUST be verified by another developer. Feel free to do this on the ML, or on IRC - just somewhere where we can look back on the logs if there are issues. -- Aaron
1) I'm fine with a testing pipeline like Debian and Gentoo have. It should be easy to move a pkg from testing to core via a small script or even a webfrontend (afaik this has been discussed in the repoman list). 2) We should have that for extra too. 3) What about clear minor fixes? Any exceptions allowed to do allone when noone is around for while? 4) Do now all developers have core access? 5) We would need something new for what we now use the testing repo - the rebuilds/updates we expect issues. We should not mix this with the the has-to-be-signed-off repo or we will get weird linked packages. Andy
On 10/7/07, Andreas Radke <a.radke@arcor.de> wrote:
1) I'm fine with a testing pipeline like Debian and Gentoo have. It should be easy to move a pkg from testing to core via a small script or even a webfrontend (afaik this has been discussed in the repoman list).
Yeah this can be scripted... a re-tag in cvs, then moving the pkgfile from testing to core should be easy. Anyone want to throw a script together for that?
2) We should have that for extra too.
Sure, but all in due time. Right now core is critical. Packages in extra aren't AS critical. I want to enforce this NOW for core. Then get some stuff on the dashboard for this... so we actually have tools to work with before enforcing it with a larger package set like that.
3) What about clear minor fixes? Any exceptions allowed to do allone when noone is around for while?
Well, if we do the exception route, who's to say what is minor and what is not. Who decides? The broken packages in the past were probably broken due to thinking "it's just a small change". I guess technically, if you're sure it's minor, you can have someone else test without pushing directly to testing, but I'd prefer not to do something like this. I mean, there's not much harm if a package is a day after the release, is there? People using testing are still on the bleeding edge.
4) Do now all developers have core access?
I'm pretty sure this was done a while ago. Almost everyone has cvs-arch access.
5) We would need something new for what we now use the testing repo - the rebuilds/updates we expect issues. We should not mix this with the the has-to-be-signed-off repo or we will get weird linked packages.
You're probably right, BUT, we can deal with that in the interim by properly communicating and coordinating until we can get a real solution in place.
participants (2)
-
Aaron Griffin
-
Andreas Radke