Alec Warner wrote: > On 10/15/07, Doug Goldstein <[EMAIL PROTECTED]> 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. >>> >>> >>> jonathan. >>> >>> >> 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.
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. 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. Then again, this depends on the QA guys actually doing something about the outstanding bugs. -- [EMAIL PROTECTED] mailing list
