I maintain very few packages these days, so it was quite a surprise to me today when I discovered that peer review is now effectively a part of the x86 stabilization process. When I wrote GLEP 40, the problem that I was trying to solve was that of devs stabling packages without ever testing the package on an actual stable system (because most devs run ~arch). As such, the language in GLEP 40 essentially suggests that devs could still stable their own packages, but only if they were properly testing the package on a stable system. That policy has evolved over time to one where devs are actively discouraged from stabling their own packages, thereby ensuring that at least one other person examines and tests the ebuild before it becomes stable. (I'm still not quite sure of the actual procedure, so I'm not sure how many people are generally involved in this peer review process.) From a QA perspective, more eyes can only be a good thing, and this idea has been tossed around on-and-off for years. On the other hand, peer review could potentially really slow things down, which is why we'd always rejected that approach in the past. Are other arch's also requiring peer review? Do we have any statistics or anecdotal evidence for what's improving, and whether or not anything is getting worse as a result?
-g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76
pgpcIG0ZQQWuA.pgp
Description: PGP signature
