public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-project]  Commit reviews
       [not found]         ` <4713D43A.9080107@gentoo.org>
@ 2007-10-15 22:06           ` Steve Long
  2007-10-16  3:49             ` Alec Warner
  0 siblings, 1 reply; 2+ messages in thread
From: Steve Long @ 2007-10-15 22:06 UTC (permalink / raw
  To: gentoo-project

Doug Goldstein wrote:
> Alec Warner wrote:
>> On 10/15/07, Doug Goldstein <cardoe@gentoo.org> 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.

> 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



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [gentoo-project] Commit reviews
  2007-10-15 22:06           ` [gentoo-project] Commit reviews Steve Long
@ 2007-10-16  3:49             ` Alec Warner
  0 siblings, 0 replies; 2+ messages in thread
From: Alec Warner @ 2007-10-16  3:49 UTC (permalink / raw
  To: Steve Long; +Cc: gentoo-project

On 10/15/07, Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Doug Goldstein wrote:
> > Alec Warner wrote:
> >> On 10/15/07, Doug Goldstein <cardoe@gentoo.org> 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



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-10-16  4:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20071013004453.GM23990@supernova>
     [not found] ` <20071014045010.GS23990@supernova>
     [not found]   ` <47137849.7030608@utas.edu.au>
     [not found]     ` <47137B11.1070003@gentoo.org>
     [not found]       ` <b41005390710151214u3581ac0emaba7763cae55ad70@mail.gmail.com>
     [not found]         ` <4713D43A.9080107@gentoo.org>
2007-10-15 22:06           ` [gentoo-project] Commit reviews Steve Long
2007-10-16  3:49             ` Alec Warner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox