From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1IhdbG-000292-G4 for garchives@archives.gentoo.org; Tue, 16 Oct 2007 04:00:10 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.1/8.14.0) with SMTP id l9G3ngXZ020815; Tue, 16 Oct 2007 03:49:42 GMT Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by robin.gentoo.org (8.14.1/8.14.0) with ESMTP id l9G3ngDa020810 for ; Tue, 16 Oct 2007 03:49:42 GMT Received: by nf-out-0910.google.com with SMTP id f5so1592868nfh for ; Mon, 15 Oct 2007 20:49:41 -0700 (PDT) Received: by 10.78.204.1 with SMTP id b1mr4548740hug.1192506580883; Mon, 15 Oct 2007 20:49:40 -0700 (PDT) Received: by 10.78.52.6 with HTTP; Mon, 15 Oct 2007 20:49:40 -0700 (PDT) Message-ID: Date: Mon, 15 Oct 2007 20:49:40 -0700 From: "Alec Warner" Sender: antarus@scriptkitty.com To: "Steve Long" Subject: Re: [gentoo-project] Commit reviews Cc: gentoo-project@lists.gentoo.org In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071013004453.GM23990@supernova> <20071014045010.GS23990@supernova> <47137849.7030608@utas.edu.au> <47137B11.1070003@gentoo.org> <4713D43A.9080107@gentoo.org> X-Google-Sender-Auth: c0abc3de6d579ab3 X-Archives-Salt: d9a4c3f9-aafd-48e1-84e1-f82555f4bd8f X-Archives-Hash: fca6eb12a8c2e551082014c55386507f On 10/15/07, Steve Long wrote: > Doug Goldstein wrote: > > Alec Warner wrote: > >> On 10/15/07, Doug Goldstein wrote: > >>> Jonathan Adamczewski wrote: > >>>> Doug Goldstein wrote: > >>>>> That's what this commits review list feels like. > >>>>> > >>>> Nearly every suggestion (from Donnie and others) has been over some > >>>> issue that relates directly to either correctness or maintainability. > >>>> It doesn't matter if you can "rattle off capabilities to a millimeter" > >>>> - if they're not documented somewhere (like, say, in the comments of > >>>> the ebuild) then the maintainer that comes after you gets to go and > >>>> break it all over again. > >>>> > >>> Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild. > >>> Do it. I dare you. Then try to compile. > >>> > >>> Guess what? When it blows up... that's called INcorrect. The opposite of > >>> the right thing. > >>> > >>> The maintainer who comes after me would be someone with a experience > >>> with the package. Some bumkin isn't going to come to maintain package > >>> XYZ unless they know or use the package, and guess what? That means > >>> experience. > >> > >> I think this assumption is false. People maintain packages they don't > >> know the intricate details of all the time. You are of course, free > >> to ignore any and all suggestions offered; but you are not allowed to > >> silence them. > >> > >> -Alec > >> > > I must have not received my silence/moderate remote control for the > > Gentoo mailing lists. Since I haven't received it, I clearly can't > > silence anyone on the mailing lists. > > > Since we're not discussing the technical content any more, but whether the > commit reviews should happen at all, I thought i'd bring this to the > project list. Please don't take that as criticism: I appreciate many of > your peers see "take it to project" as an insult, but it's actually a good > thing: you have more latitude to discuss what's annoying you. > > > I still stand by my original feeling that we'd better the community NOT > > only the developers doing the commits by updating the devmanual, which > > is accessible to all developers and all users in the Gentoo community. > > In addition to updating and cleaning up repoman checks, which is a tool > > that everyone in the community can use. This is versus individual > > examples in random ebuilds in random e-mails that all have almost an > > identical subject on the mailing list. > > > I agree the devmanual and repoman should be updated, but not that the > reviews shouldn't happen. For a start it's interesting to see the ins and > outs of ebuilds we'd never otherwise look at, and it's even more > interesting to see the stuff that causes an issue, eg an upstream configure > script that can't take spaces in prefix. > > If the reviews bother you, you can surely set a procmail filter which only > allows your ones through? > > > The commits review is flawed because if we're not documenting this stuff > > in one central place, then when new developers join. The same lessons > > have to be learned over and over again. > > > Sure, so file a patch to devmanual for stuff that's missing? Or just tell us > the rough details here and it can be discussed before some of us lowly > users file a patch. I have a checkout of the devmanual and I'm working on adding some bits. Patches are always welcome, the source is at http://sources.gentoo.org/viewcvs.py/devmanual/ or svn co http://anonsvn.gentoo.org/repositories/devmanual or for developers: svn co svn+ssh://user@svn.gentoo.org:/var/svnroot/devmanual > > > Then again, this depends on the QA guys actually doing something about > > the outstanding bugs. > Well there'll be an awful lot less bugs hitting user systems now that every > ebuild is reviewed and errors are brought to the list, I'd imagine. After > all, peer review (or the fear of it ;) is what makes Open-source software > such high-quality. > > Is there a specific area you feel QA is falling down on? If so, please tell > the community, and maybe we can help. I know several users who take > pleasure in fixing bugs (and don't want the hassle of being a dev) and many > more discuss a bug on the forums (often one they've found) before filing a > patch. > > > -- > gentoo-project@gentoo.org mailing list > > -- gentoo-project@gentoo.org mailing list