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