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

[M. J. Everitt]

On 14/05/16 12:35, Ciaran McCreesh wrote:
> On Sat, 14 May 2016 11:55:42 +0200
>> Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
>>> On Sat, 7 May 2016 23:25:58 +0200
>>>> Do you seriously expect this code to work? How about testing? Or
>>>> reading diffs before committing?
>>> Do you seriously expect us to sit and absorb this form of pious
>>> put down? From one who knows far better who is entitled to speak
>>> down to colleagues as is completely lacking a cerebral cortex?
>>> Those times are drawing to an end. Did anyone ever teach you to
>>> treat folk in such manner and expect them to respect it? I don't
>>> think so Not over my dead cvs perhaps
>> Well, we still do need some commit quality, you know...
> Why? Gentoo is about the community. Requiring a basic standard of commit
> quality a) reduces the number of community members who are able to
> contribute, 2) leads to fewer forums posts discussing how to fix
> problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
> volume of commits, and fourthly, discriminates unfairly against
> competency-challenged developers by imposing subjective interpretations
> of the value of source code from a position of unearned authority. This
> is against the code of conduct, and is bad for the community!
>
In defense of Gentoo at large .. the entry-level to contribute is really
quite low .. and all the documentation for gentoo 'standards' is widely
documented in both the Devmanual (under revision currently) and the
Package Manager Spec. Not only this, but there are active projects
within gentoo to welcome, nurture and develop devs and contributors
alike so that there is a sustainable level of man-power available to
keep up with the demands of users and pace of code development. Ok, it
can be off-putting to those looking in from the outside, but really I
think it benefits more than it costs.

I agree broadly with the ethos of the QA team, gentoo tends to focus on
quality over quantity where commits are concerned. It's better to retain
a stable, reliable set of packages, with additional untested/unstable
packages available via overlays, rather than a massive, unwieldy number
of packages in a broadly unknown state. As it is, there is a deficit of
active people maintaining the less-widely used packages, and also people
able to add new packages to the tree, and this means that resources are
inevitably spread more thinly.

As always there will be a balance, but this thread did start out with
some tit-for-tat between devs, totally unnecessary either in private or
public. So, ditch that bike-shed, and get on with fixing bugs, closing
issues, adding, updating and deprecating packages, folks :]. Thank you.