* Neal Gompa:
You're confusing this with trust. And yes, there's some trust
to give
here, but keeping a (tiny) amount of friction for small patch sets
that increases as your patch load goes up just further encourages not
maintaining heavy patch loads.
Heavy patch loads are just a fact of life. Currently, Fedora 28 glibc
is at ~90 upstream patches. Fedora 27 glibc was at ~190 upstream
patches at end of life (depending whether you count the last update that
didn't make it before EOL). The few Fedora-specific patches come on top
of that.
For comparison, Red Hat Enterprise Linux 7 glibc is currently at around
880 patches. Most of them a straight upstream backports, as in Fedora.
The overhead from managing those patches used to be substantial, but we
have mostly automated it, in a different way from the kernel and Red
Hat's middleware products, because Fedora would not allow us to use
established downstream practices. Unfortunately, our automation is
still somewhat brittle and incomplete. It still takes around seven
minutes to prepare the sources for a totally trivial upstream backport
of a single patch, something that should ideally be a single “git
cherry-pick” command (which would also leave less room for mistakes).
Of course, in seven minutes, you can fill in a lot of patch
documentation that allows you to figure out later what you did and why.
I'm worried that this kind of pointless work makes it hard to attract
talent.
Thanks,
Florian