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 |