Gentoo Archives: gentoo-dev

From: Mark Loeser <halcy0n@g.o>
To: gentoo-dev@l.g.o, gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] evolution of x86 stabling procedures
Date: Mon, 05 Jun 2006 20:33:48
Message-Id: 20060605202502.GJ15987@aerie.halcy0n.com
In Reply to: [gentoo-dev] evolution of x86 stabling procedures by Grant Goodyear
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