On 05/15/2016 03:29 AM, Michał Górny wrote: > On Sun, 15 May 2016 08:40:39 +0900 > Aaron Bauman <b...@gentoo.org> 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 <b...@gentoo.org> 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 <mgo...@gentoo.org> 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
signature.asc
Description: OpenPGP digital signature
