On Tue, Jun 29, 2021 at 7:35 AM Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
Lo!
On 28.06.21 22:10, Justin Forbes wrote:
> If you have a pending merge request, you will need to rebase your
> source tree and force push so that things will cleanly merge.
>
> While this is the first time we have done this for os-build, we expect
> to keep it up as a cadence with every upstream release. This means we
> will do it again when 5.14 releases, and again with 5.15... […]
BTW, does anyone occasionally review the patches to check which ones
still need to be upstreamed or maybe can be dropped? To me it looks like
it would be a good idea after a quick review:
We don't have a specific schedule to do so. It has been done in the
past, but it ends up being pretty random. I think it has been a couple
of years at this point. It would be good to do so on a more regular
basis. Perhaps every 5 upstream releases?
I looked at
https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/Patchlist.changelog
and randomly picked one that didn't look like it was RHEL specific. It
was this one:
https://gitlab.com/cki-project/kernel-ark/-/commit/5ef51389cf6673a0e9e004...
Looks to me like it was never merged upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/dr...
For a quick search it looks like things stalled here:
https://lore.kernel.org/lkml/20170331085751.GF22683@mail.corp.redhat.com/
Funnily enough it seems that patch was fixing a regression I ran into
myself back in 2017 (yes, I really picked that patch from the list
nearly at random; I can't even remember that regression). But seems it
was fixed somewhere/somehow/somewhen, because until recently I regular
used the particular XPS13 with vanilla kernels and never noticed any
touchpad problems (I can recheck the dmesg output if anyone is
interested, I still have access to the machine occationally).
Okay, it was good/bad luck that I immediately picked one that looks
obsolete, but it IMHO clearly shows that revisiting the patches every
now and them might be good idea, which made me write this mail. Don#t
known, maybe even some kind of policy like "after one/two years somebody
has to vouch for a patch, otherwise it gets dropped" might be a good idea?
Side note: All those RHEL-only patches make it look like the Fedora
kernel is quite a bit modified, which might be bad for Fedora's
reputation. If they really have to be there (do they?), can't they at
least be marked more clearly? Maybe when generating Patchlist.changelog
add "RHEL-only: " to the description if the commit message contains
"RHEL-only"?
That makes it a bit more difficult because we generate the patch list
with a simple git log output, and don't actually look at the entire
commit message. Also, some of them are not clearly labelled. Most of
those patches are simple support housekeeping such as marking specific
hardware as deprecated and the like. I do drop all of those RHEL
specific patches when I do the rebases on fedora-5.x branches so they
are not carried in Fedora stable releases at all. I maintain a list
of them so that I can drop them when we rebase to create those
branches. It might be good to add that list to the redhat directory.
Justin