On Wed, Jan 06, 2021 at 06:07:40AM -0500, Elliott Sales de Andrade wrote: > As a first order estimate, it's rather straightforward to grab the > spec tarball and count the number of Patch lines in each one (which > ignores any fanciness with Lua or conditionals, and doesn't really say > if they are downstream-only, exactly). > > The top ten count percentages are: > 0 71.5054 > 1 14.7853 > 2 5.6351 > 3 2.7172 > 4 1.4361 > 5 0.9893 > 6 0.6611 > 7 0.4468 > 8 0.3419 > 9 0.2234 > 10 0.1824 > >10 1.0760 > > So at minimum 71.5% have no downstream-only patches. I _think_ > packages with fewer patches are ones that will likely go upstream Many thanks for calculating those statistics! Even looking at the list below, not "go upstream", but "come from upstream". That is one of the changes from what was happening 10 years ago and now that I was trying to highlight. We pull patches from upstream repos, and more rarely then before generate them downstream. And even if we generate them downstream, we're more likely to immediately submit them as pull requests or such. (In particular, when trying to fix some build or failing test, I find it less work to clone the upstream repo and work there and immediately submit a pull request and use Patch0: https://github.com/.../something.patch in the spec file, so that I can do 'spectool -g *spec', instead of generating the patch file myself.) I'm pretty sure that the 81 python3-rpm are backports from upstream. The 129 patches for gcl seems to be upstream prerelase patches. When upstream makes the next release, no "rebase" is needed — those patches will be just dropped. Zbyszek > having more patches might indicate that upstream is dead/dying/slow to > release), so the remaining ones with less than 5 are _likely_ to go > upstream. Just guessing that's about half of those would be another > ~12%, so around 84%. > > For anyone interested in top-patchers: > patch_count > cc65 170 > gcl 129 > device-mapper-multipath 87 > python3-rpm 81 > luajit 79 > ksh 71 > kdelibs3 68 > vsftpd 68 > acpica-tools 62 > ovn 61 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
