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

[Gregory Woodbury]

On Tue, Oct 31, 2017 at 10:22 AM, Rich Freeman <rich0@g.o> wrote:
> Me, earlier the same date, writing:
>> 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.

TL;DR: More commentary about attitudes of some FOSS developers in
recent times, and some history about init systems, sort of
autobiographical. And finally, a tentative proposal for a position
somewhere between a developer and an outsider involved with the
community. I apologize that it is too long.

Well, I understand this, but this is one of the things that bothers me
about recent Open Source development.  I came up through the "pioneer
days" of computing, and, when proprietary stuff wasn't involved,
sharing, cooperation, and getting stuff done "soonest" was a general
principle. On USENET (before the Eternal September) being timely and
making and meeting commitments was expected behavior. Yes, the people
were volunteers, and did things as they had time for them; but they
felt a dedication to being professional in all their programs, free or
paid. Linux itself emerged in this manner, the GNU userland emerged
from a similar background. The programmers felt a commitment to
providing a good program, and in responding to suggestions and
constructive critique.

In the last decade or so, a new crop of FOSS programmers has emerged;
they do the programs to suit themselves (or their employers if they
are fortunate), but they don't really give a damn about the users
outside of their immediate concern, they do what they want - whether
or not it has major ramifications on a whole operating "ecosystem"
(such as forcing users/admins/etc to rearrange how they have major
part of their systems setup by ignoring standards and rationale that
says 'all programs necessary to boot the system should go on the root
filesystem' - by putting their stuff on /usr/... so that root now has
to be merged with /usr, or they have to change how their machines boot
by using a new and esoteric kernel addition.) [In terms of this "civil
war", I was told explicitly by the writers that they didn't care about
the 'suggested standard' - they put it where they wanted it, and if an
admin didn't want to depend on /usr being mounted at early boot (or an
initrd image with their stuff on it) they could dig in and change the
way it compiles and installs (as well as fix up all the hard-coded
references!)]

And a lot of other FOSS developers explicitly supported that attitude
- "you're lucky we decided to make it available at all, if you don't
like it: write it yourself."  Yes, I *could* write it myself if I had
the ability to devote my full time to producing a competing system. I
should not have to. What they have produced it actually quite a nice
invention, but it is, in my not so humble opinion, too large, too
intrusive, and requires many other programs to adapt to their way of
doing things or else. The Gentoo USE flags for their way are scattered
all over the place in our ecosystem. The old UNIX philosophy of a
'program should do one thing - and do it well' with the ability to
"pipe" the output of one program to another and another...  has gone
right out of the window.

I will admit to having a bias much in favor of the OpenRC methods.
OpenRC adheres to the precepts of the original System 5 UNIX method of
trying to be a capable as necessary without letting "feeping
creaturism" destroy the elegance of the solution. When writting
SysVInit  (actually for System IV in 1981 - an internal development
version at Bell Labs) we spent a lot of time scratching our heads to
come up with a way to programmaticly solve the deep problem of getting
the order of service activations correct. The limited processor
speeds, the limited memory sizes and lack of mathematical methods
developed years later, caused us to "punt" the problem to the best
processor for the task at the time - the human mind. With a bit of
practice, admins could come up with the proper sequencing much faster
than any computer of the era. We worked hard to keep the init system
out of the way of the other programs that it was responsible for
starting, and out of the way of the user at the keyboard. We did ask
for and got a small change/enhancement to the Bourne shell - a way to
change the input and output connections of a shell program. These
days, OpenRC uses techniques we didn't know about to allow each
startup script to specify the services it depends on and what it
provides, and then to solve the sequencing needs, and store the
results for use. Each script did one setup phase, and did it well;
then it handed control back for the init process to do the next phase.
It stayed out of the way otherwise.

So, you see, I did write major pieces of the SysVInit suite. There is
an extreme distaste in my soul left from the attitudes and invective
hurled by the developers and supporters of the latest major init
system around the time of its introduction. Their attitude of 'we
don't care about standards', 'so you have to totally rearrange you
partition allocations - tough', and 'if you don't like it go write one
yourself.' I retired on disability 10 years or so ago, I lost my wife
and best friend 6 years ago, and am aging in place in the community. I
have time, I have skills, but I need a fair bit of managerial
attention to keep my days in order. I can contribute just as much at
this point using bugzilla, and I don't really want commit access, and
I apologize for calling the Council inbred. But it would be a sign of
respect and/or honor to be able to be called something like an
associate developer with a voting privilege (maybe) and thus be able
to join teams to contribute more actively. I probably would not
require anything more than a relay @gentoo.org address, no blogs, no
personal directory trees or webpages, maybe a directory space for
uploading large bits of code when needed. Is it worth considering?

Just another too long commentary.