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?

Grant Goodyear  
Gentoo Developer
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

Attachment: pgpcIG0ZQQWuA.pgp
Description: PGP signature

Reply via email to