On Tue, Jun 29, 2021 at 7:35 AM Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> 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/5ef51389cf6673a0e9e004909c7be1dc785050b2 > > Looks to me like it was never merged upstream: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/hid/hid-rmi.c > > For a quick search it looks like things stalled here: > https://lore.kernel.org/lkml/20170331085751.GF22683@xxxxxxxxxxxxxxxxxxxx/ > > > 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 _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-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/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
