* 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
