Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

On 05/15/2016 03:29 AM, Michał Górny wrote:
> On Sun, 15 May 2016 08:40:39 +0900
> Aaron Bauman <bman@g.o> wrote:
>
>> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
>>> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@g.o> wrote:
>>>> On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:
>>>>> On Sat, 7 May 2016 23:25:58 +0200
>>>>>
>>>>> Michał Górny <mgorny@g.o> wrote:
>>>>>> Do you seriously expect this code to work? How about testing? Or
>>>>>> reading diffs before committing?
>>>>
>>>> Absolutely nothing wrong was said here.  Obviously the code was not tested
>>>> and Michal pointed that out very plainly.
>>>
>>> It is actually possible to communicate both plainly and politely at
>>> the same time.  This does not require sacrificing any commitment to
>>> quality at all.  Really the only downside is having more of an
>>> appearance of professionalism.
>>
>> Please enlighten me as to what was impolite here?  The strong language of
>> "seriously" or definitively stating that the individual did not perform the
>> necessary QA actions before committing?  Both of which are completely called
>> for and appropriate.  No vulgarity, insults, or demeaning words were used.
>> How would you have responded professionally?
>
> Since the anti-productivity of this thread is getting impressively high
> even for Gentoo standards, I'd like to point out a few things.
>
> It was impolite. It was supposed to be. Not offensive but impolite. It
> ain't cool to get responses like this but it ain't cool to break stuff
> like this either.
>
> For those who don't have a broader view, it wasn't a single commit but
> a followup to a commit adding EAPI=6 support to the eclass -- clearly
> untested. I didn't bother complaining about the first one since issues
> would clearly pop up if someone actually tried to use the eclass
> in EAPI=6. However, the second commit actually introduced a syntax
> error that broke all the ebuilds, including stable and caused metadata
> generation failure. This is real bad.
>
> Of course, it could have been worse. It looks like no ebuilds with
> EAPI=6 'support' were committed following the eclass. Which is a good
> sign that some testing eventually occurred. However, is it that much of
> an effort to test eclass changes using ebuilds *before* committing it?
> It wasn't that hard even in times of CVS (esp. that we're talking about
> separate directories), and it is even easier in times of git.
>
> I don't really see the benefit of whole of this discussion. He
> committed a bad thing, I shouted at him, end of story. If you want to
> take it to comrel, just do it. However, discussing whether it was right
> or wrong is really unproductive here.
>
I felt it was a bit strong, but you make a good case. There certainly is
a balance. One can't coddle someone who's breaking the tree, especially
when we expect people to test before committing. Since it was an eclass,
wasn't that supposed to be discussed on here first, too? Still, we're
going to make mistakes and dressing someone down won't fix it.

When I was adding multilib support to media-sound/apulse I recall you
strongly telling me that I screwed up and it shouldn't have been done
the way I originally committed. There wasn't a nudge in the right
direction, though. I imagine it was clear that I hadn't done multilib
scripts before. If I had been more sensitive or less willing to fix it,
what would have happened? You or someone else may have reverted it
and/or reported to QA and started a ruckus.

I mean, I don't hold a grudge or anything. I'm glad you told me it
wasn't right, because if I'm contributing to Gentoo I want it to be done
well. I learned something from it. But a dev being told that they're
screwing up without also being specific (or at least a hint) about a way
to fix it or *why* it's wrong doesn't help them fix their screw up and
ensure it doesn't happen again.

That sort of criticism, which may be warranted in terms of "they screwed
the tree up due to something stupid!", isn't productive if the dev
doesn't know how to fix it.

This particular screw-up is different since it was simpler, but less
trivial screw ups do happen and without _constructive_ criticism, devs
(and Gentoo, by extension) won't get better.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6