Re: [gentoo-project] Discontinuing the support for GitHub pull requests

[Rich Freeman]

While I think you raise a few good points, I will just reply to a few
things I think you should consider differently:

On Tue, Oct 31, 2017 at 6:50 AM, Gregory Woodbury <redwolfe@×××××.com> wrote:
> Many of them
> are already familiar with the methods and tools, and it is insulting
> that they would
> have to go through an "apprenticeship" before they are allowed to even
> submit patches.

Nobody is required to go through any kind of apprenticeship/etc just
to submit patches.  Anybody can register on bugzilla, or github, and
submit either patches as attachments or pull requests.

Being able to commit them to the official repository is another
matter.  But, anybody can of course host or use any unoffiicial
repository they wish to.  Our standards for even listing these in the
official layman list aren't all that high either.

> With such a background, I find the "required" hoops of the Gentoo
> developer admission process very insulting, especially in light of the
> politics I have observed; and I have no patience or inclination to deal
> with it just to become a member of the "inner circle" and get a chance
> to obtain commit access and to vote for the inbred council.

IMO technical ability actually isn't the most important consideration
when giving people either commit access or the right to vote for the
Council.

Consider two people with commit access:

The first knows very little of programming.  They can't fix most
issues.  However, they understand the limits of their knowledge and
focus only on issues where they're confident that they can apply a
correct fix.  When they do make commits they're correct, even if
they're fairly limited in scope.

The second knows a great deal about programming/linux/etc.  They can
solve very complex issues.  However, they tend to be a bit sloppy and
love to write scripts that go making commits all over the repository
and they're the frequent target of complaints by others who have to
clean up their mistakes.

I'd argue that the first person is somebody you want to give commit
access to, and that the second person should be limited to submitting
pull requests/patches that go through somebody who is more responsible
before they can go into the repository.  They may have great ideas,
but you can't have QA if you let people be sloppy.

Also, how do you intend to fix social issues like how devs mistreat
each other, if you don't use this as a criteria before letting people
decide who is allowed to vote for the Council?

>
> After 59 years of programming, admining (excuse me - DevOps), testing,
> on a wide variety of platforms, I can be cranky and fussy. The thing is:
>        I do care about Gentoo.

Most personal conflicts around here are between people who care about
Gentoo.  If they didn't care and feel they had a stake in the
direction things go, they wouldn't spend their time posting.

> I can see the politics (which is the art of dealing with groups of people),
> and even occasionally contribute to it; and I can ignore it when necessary.
> I will continue to use Gentoo, and make bug reports, submit patches
> via bugzilla and just carry on until my body no longer can function. I would
> like to see Gentoo become more open and much less political. But I won't
> bet the farm on that happening.

You seem to want more openness, less infighting, and less politics.
These seem somewhat mutually inclusive.  How do you have less
infighting if you are open about accepting people who fight?  How do
you deal with people who do fight without politics?

Sure, in an ideal world everybody would get along.  In an ideal world
projects would get done with high quality, low cost, and in little
time.  In the real world we usually have to compromise on some of
this.

> P.S: Just a thought: make every developer an automatic member of a
> QA project, with a goal of getting proposed patches reviewed within
> 90 days of being submitted.

It is hard to reconcile time limits with volunteer efforts.  If
somebody doesn't close a bug in 90 days for a package for which
they're the sole maintainer, do we remove the package from the tree?
If a user submits a bug do we end up punishing them by removing their
favorite package entirely because it has an unresolved bug?

A lot of rules/incentives/etc end up not working the way you might
expect them to in a volunteer project.  You'll quickly be confronted
with cases where the rule wasn't followed, and then you have to decide
what the recourse actually is, and often your only practical options
are ones that are worse than the problem they were intended to fix.

> The possessiveness of (some/many/most)
> developers is one of the wort aspects of Open Source programming these
> days, and Gentoo is rife with it (but not as bad as some other well-known
> Linux projects.)

While there is some of this I think that it really only persists when
nobody else wants to get involved with something.  In this situation
I'm not sure you can really call it "possessiveness."

If Joe is the only developer willing to maintain package foo, then the
reality is that Joe basically ends up getting to call most of the
shots.  Assuming nobody else wants to maintain it, then our only real
alternative is to block Joe from maintaining foo at all, which is a
solution that is probably worse than the problem.

Now, if Adam is also willing to maintain foo then we have options.
The policy in this situation with Gentoo is that Adam is allowed to
co-maintain, and Joe has to work with Adam whether he wants to or not.
If Joe isn't able to do so, then this needs to get escalated, and
worst case we can always tell Joe to not maintain foo while not
leaving it unmaintained.  In an ideal world they work together, and in
practice this usually happens.  When it doesn't then we're back to
politics.

I realize I only replied to the things I disagree with, and I just
wanted to close to say that I agree with some of the overall sentiment
and don't want to fail to acknowledge that.  I think a lot of people
would agree that finding better ways to incorporate contributions of
non-devs would be very desirable.  This is part of why I'd hate to see
the github PRs go away.  Hasufel was a major proponent of a more
Devs-are-review/QA mindset.  I think that reality will be a compromise
- devs are always going to tend to want to scratch their own itches,
which means that they're going to want to spend more efforts on
writing and committing their own patches than reviewing patches
submitted by others for software they aren't interested in.

-- 
Rich