Re: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)

>
> I wrote up a couple more paragraphs about why I think it happens and
> what we'd need to do to import more of that sense over into src.  But
> it was way longer than it needs to be.  We get a lot more man-hours in
> ports/ acting as conduits for the "outside patches -> svn" pipeline
> because the incentives are rigged.  A bad outside contribution brought
> into ports more often yields "hey, you should have noticed" to the
> committer and more opprobrium back to the submitter.  A bad outside
> contribution brought into src falls all over the commiter.
>
> Not entirely unreasonable, since a lot of even small-ish breakages in
> src are much bigger deals than even large-ish breakages in ports.  But
> it still makes it expensive to contemplate being a conduit...

Whereas the incentives in ports are structured such as to encourage
being a conduit and arguably it's a big part of being a responsible
porter, in src there is an active disincentive. A committer invites
substantial criticism by breaking src by importing a change but
invites no criticism for ignoring review requests or patches. There
are a few people who go through the pain of wading through patches and
committing them but as a general rule one has to have some level of
rapport with a proxy to get changes in without a bit. Whereas with
TrueOS the Git PR system lets one submit a change, the CI system
builds it to verify, and then it's thumbs up or thumbs down and it
goes in, undergoes further review / refinement, or is rejected
outright. There's something to be said for automation.

Submitting enhancements is even harder. There's always someone who
will be upset by a change in existing behavior, no matter how logical
a change may seem to the rest of us. This obvious change is almost 10
years old and seems completely common sense:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139389

I've been keeping it in my bookmarks hoping that Eitan will commit it,
but may at some point overcome my reservations and just go ahead and
commit.

My problem with the bug system is classification. If a bug report
refers to something I touched recently, it's easy to assign it to me.
However, when I've tried wading through the bug system to find things
that I might be able to fix, I have not found it easy at all. This is
where culling older bug reports comes in. With a poor signal to noise
ratio from too many PRs, what really happens is _fewer_ things get
fixed, not more.

Cheers.
-M