Gentoo Archives: gentoo-project

From: Alec Warner <antarus@g.o>
To: Steve Long <slong@××××××××××××××××××.uk>
Cc: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Commit reviews
Date: Tue, 16 Oct 2007 04:00:10
Message-Id: b41005390710152049v4a66186bt27f73940bb5a1c36@mail.gmail.com
In Reply to: [gentoo-project] Commit reviews by Steve Long
1 On 10/15/07, Steve Long <slong@××××××××××××××××××.uk> wrote:
2 > Doug Goldstein wrote:
3 > > Alec Warner wrote:
4 > >> On 10/15/07, Doug Goldstein <cardoe@g.o> wrote:
5 > >>> Jonathan Adamczewski wrote:
6 > >>>> Doug Goldstein wrote:
7 > >>>>> That's what this commits review list feels like.
8 > >>>>>
9 > >>>> Nearly every suggestion (from Donnie and others) has been over some
10 > >>>> issue that relates directly to either correctness or maintainability.
11 > >>>> It doesn't matter if you can "rattle off capabilities to a millimeter"
12 > >>>> - if they're not documented somewhere (like, say, in the comments of
13 > >>>> the ebuild) then the maintainer that comes after you gets to go and
14 > >>>> break it all over again.
15 > >>>>
16 > >>> Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild.
17 > >>> Do it. I dare you. Then try to compile.
18 > >>>
19 > >>> Guess what? When it blows up... that's called INcorrect. The opposite of
20 > >>> the right thing.
21 > >>>
22 > >>> The maintainer who comes after me would be someone with a experience
23 > >>> with the package. Some bumkin isn't going to come to maintain package
24 > >>> XYZ unless they know or use the package, and guess what? That means
25 > >>> experience.
26 > >>
27 > >> I think this assumption is false. People maintain packages they don't
28 > >> know the intricate details of all the time. You are of course, free
29 > >> to ignore any and all suggestions offered; but you are not allowed to
30 > >> silence them.
31 > >>
32 > >> -Alec
33 > >>
34 > > I must have not received my silence/moderate remote control for the
35 > > Gentoo mailing lists. Since I haven't received it, I clearly can't
36 > > silence anyone on the mailing lists.
37 > >
38 > Since we're not discussing the technical content any more, but whether the
39 > commit reviews should happen at all, I thought i'd bring this to the
40 > project list. Please don't take that as criticism: I appreciate many of
41 > your peers see "take it to project" as an insult, but it's actually a good
42 > thing: you have more latitude to discuss what's annoying you.
43 >
44 > > I still stand by my original feeling that we'd better the community NOT
45 > > only the developers doing the commits by updating the devmanual, which
46 > > is accessible to all developers and all users in the Gentoo community.
47 > > In addition to updating and cleaning up repoman checks, which is a tool
48 > > that everyone in the community can use. This is versus individual
49 > > examples in random ebuilds in random e-mails that all have almost an
50 > > identical subject on the mailing list.
51 > >
52 > I agree the devmanual and repoman should be updated, but not that the
53 > reviews shouldn't happen. For a start it's interesting to see the ins and
54 > outs of ebuilds we'd never otherwise look at, and it's even more
55 > interesting to see the stuff that causes an issue, eg an upstream configure
56 > script that can't take spaces in prefix.
57 >
58 > If the reviews bother you, you can surely set a procmail filter which only
59 > allows your ones through?
60 >
61 > > The commits review is flawed because if we're not documenting this stuff
62 > > in one central place, then when new developers join. The same lessons
63 > > have to be learned over and over again.
64 > >
65 > Sure, so file a patch to devmanual for stuff that's missing? Or just tell us
66 > the rough details here and it can be discussed before some of us lowly
67 > users file a patch.
68
69 I have a checkout of the devmanual and I'm working on adding some
70 bits. Patches are always welcome, the source is at
71 http://sources.gentoo.org/viewcvs.py/devmanual/
72 or
73 svn co http://anonsvn.gentoo.org/repositories/devmanual
74 or for developers:
75 svn co svn+ssh://user@××××××××××.org:/var/svnroot/devmanual
76
77 >
78 > > Then again, this depends on the QA guys actually doing something about
79 > > the outstanding bugs.
80 > Well there'll be an awful lot less bugs hitting user systems now that every
81 > ebuild is reviewed and errors are brought to the list, I'd imagine. After
82 > all, peer review (or the fear of it ;) is what makes Open-source software
83 > such high-quality.
84 >
85 > Is there a specific area you feel QA is falling down on? If so, please tell
86 > the community, and maybe we can help. I know several users who take
87 > pleasure in fixing bugs (and don't want the hassle of being a dev) and many
88 > more discuss a bug on the forums (often one they've found) before filing a
89 > patch.
90 >
91 >
92 > --
93 > gentoo-project@g.o mailing list
94 >
95 >
96 --
97 gentoo-project@g.o mailing list