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