1 |
Grant Goodyear <g2boojum@g.o> said: |
2 |
> I maintain very few packages these days, so it was quite a surprise to |
3 |
> me today when I discovered that peer review is now effectively a part of |
4 |
> the x86 stabilization process. When I wrote GLEP 40, the problem that I |
5 |
> was trying to solve was that of devs stabling packages without ever |
6 |
> testing the package on an actual stable system (because most devs run |
7 |
> ~arch). As such, the language in GLEP 40 essentially suggests that devs |
8 |
> could still stable their own packages, but only if they were properly |
9 |
> testing the package on a stable system. That policy has evolved over |
10 |
> time to one where devs are actively discouraged from stabling their own |
11 |
> packages, thereby ensuring that at least one other person examines and |
12 |
> tests the ebuild before it becomes stable. (I'm still not quite sure of |
13 |
> the actual procedure, so I'm not sure how many people are generally |
14 |
> involved in this peer review process.) From a QA perspective, more eyes |
15 |
> can only be a good thing, and this idea has been tossed around |
16 |
> on-and-off for years. On the other hand, peer review could potentially |
17 |
> really slow things down, which is why we'd always rejected that approach |
18 |
> in the past. Are other arch's also requiring peer review? Do we have |
19 |
> any statistics or anecdotal evidence for what's improving, and whether |
20 |
> or not anything is getting worse as a result? |
21 |
|
22 |
Well, since you decided to bring this up on here, I guess we'll just try |
23 |
to address everything. |
24 |
|
25 |
I believe almost everyone has been happy with how the x86 team has |
26 |
turned out. I have only gotten positive feedback from people and users. |
27 |
Despite that, we still have some devs, and *teams*, that don't follow |
28 |
proper keywording procedures. |
29 |
|
30 |
Peer review should be part of any stablization process. The glep that |
31 |
*you* wrote even provides for it: |
32 |
|
33 |
For a package to move to stable, the following guidelines must be met: |
34 |
... |
35 |
* The relevant arch team must agree to it. |
36 |
|
37 |
Maybe it was not what you intended, but we have not been slowing down |
38 |
any process as far as I'm aware, since we get to our bugs as quickly as |
39 |
we possibly can. And every arch team has their own keywording policy. |
40 |
I don't see why x86 can not have the poilcy that we decided on. If you |
41 |
have MIPS hardware and you mark something ~mips, I'm pretty sure they |
42 |
will be pissed if they didn't give you prior permission. Probably the |
43 |
same for a few archs. |
44 |
|
45 |
The x86 team has been asking for months now that everyone files a bug to |
46 |
have their package stablized, and we allow maintainers to stablize their |
47 |
package when it is impossible for us to do so. I'm trying to figure out |
48 |
why this is a problem all of a sudden, because things seemed to be going |
49 |
just fine. |
50 |
|
51 |
Thanks, |
52 |
|
53 |
-- |
54 |
Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) |
55 |
email - halcy0n AT gentoo DOT org |
56 |
mark AT halcy0n DOT com |
57 |
web - http://dev.gentoo.org/~halcy0n/ |
58 |
http://www.halcy0n.com |