> Ah, ok. Yeah, I discussed with Justin awhile ago, about just taking patches > for Fedora from folks he trusted were taking upstream committed patches > because that is the speed Fedora is used to. I will chat with Red Hat folks > about what can be done to not get in the way. Well I'm been doing the arm/aarch64 kernel maintenance for around 8 years. > In general the concern is to make sure non-upstream'd accepted patches get reviewed. In some cases I regularly rebase some patches that are evolving upstream, if you look at the reverted patches vs the new ones they are widely different based on upstream as the patches have evolved. > So pointing to upstream commits is the easiest way to reduce that concern > (at least submaintainer commit ids as those will be the same in Linus's Yes, when there is upstream I usually would, the new way of doing things is weird, do I do it in the MR, do I have to manually edit every single patch to add RHEMisms? I do this stuff in my spare time, this is laborious ATM compared to the old work flow. > Patchwork patches don't have those ids, but I would think they are in an > arm-next branch or something?? There's a newer version of these patches upstream because the drm-misc-next where some of them have landed had other changes and they needed a rebase. In the past this was documented in the kernel.spec. > I will work on some ideas to not negatively impact your contributions. > > Thanks! > > Cheers, > Don > _______________________________________________ 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
