On 12.02.22 06:21, Neal Gompa wrote: > On Fri, Feb 11, 2022 at 11:25 AM Justin Forbes <jforbes@xxxxxxxxxx> wrote: >> On Fri, Feb 11, 2022 at 8:07 AM Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: >>> On 08.02.22 20:24, Donald Zickus wrote: >>>> >>>> It has been awhile since we changed how this mailing list is used. As >>>> folks have noticed, we have increased traffic significantly over the >>>> past couple of years to reflect the activity Red Hat developers are >>>> performing on the Fedora kernel. >>>> >>>> My question to this list is around the thoughts of this activity: >>>> * Is there too much noise? Should we throttle back? >>>> * is the volume ok? Folks have good filters? >>>> * Other suggestions on how we use this list? >>>> >>>> Trying to continue to make this mailing list useful. >>>> >>>> Thanks for any feedback! >>> >>> The mails are not a big problem for me, but they are related to a bigger >>> question that again and again pops up in my head: >>> >>> Is it really a good idea to have all those totally RHEL specific patches >>> in the Fedora rpm (and thus discussed here)? And does that approach mean >>> that Red Hat is special, or are willing to include downstream patches >>> for other distros as well? Say Amazon Linux? How is this handled in >>> other packages? Or is it an issue that only happens with the kernel? >> >> It is a trade off, and I think one that tends to be worthwhile. The >> patches that are included and discussed here also typically include >> special casing with #ifdef CONFIG_RHEL_DIFFERENCES and the code path >> does not actually impact Fedora kernel users. More importantly, those >> patches are backed out on fedora stable branches, so they only exist >> in Rawhide. Yeah, I'm glad that they are not in stable, thx for this. Still I'm not really happy with the overall situation, as those patch increases the patch count by quite a bit, which for me doesn't feel really in line with our "we are close to upstream" claim -- and makes us look bad if kernel developers, journalists and others count patches (I did that a few times when I still wrote for a living -- and actually hope to write an article about this sooner or later which takes a close look at how various vendors patch their kernels). I'm not a git master, but would it maybe be possible to have those patches in a separate branch and a separate %patch only applied for ELN? Just wondering, as upstream development mostly happens with separate branches, that's why I wonder why this can't be done here. But I fear that things are slightly different in this case and might makes things impossible in this case hard. Anyway: >> By including these and the process that brings them in to >> begin with, we also get a much larger group of the RHEL kernel >> developers, QA, etc paying attention to upstream and fixing issues >> before they make it to a stable release. > >>> Sure, Fedora is mainly sponsored by Red Hat and all Fedora kernel >>> developers are working for Red Hat, but somehow it feels to me like a >>> boundary was overstepped. >> >> I can see that point of view, and I do understand it. There is a >> tradeoff involved. While it does mean some additional overhead in >> dealing with patches that do not impact Fedora, in return we do get >> some additional kernel dev attention when we run into real issues. Yeah, that's good, I noticed. >> I >> have been a Fedora kernel maintainer for a rather long time at this >> point, and I can tell you that it used to be easier to get help with >> issues from outside resources because everyone internally was busy and >> the Fedora tree was not included in their responsibility list. This >> has gotten considerably better since we moved to the ark process, >> because suddenly the ark tree is on people's responsibility list. Sounds really good. > On the other hand, the workflow changes have certainly made the Fedora > kernel more difficult for outsiders to work with. I think what Neal wrote here hits the nail on the head. Those RHEL specific patches and the mails are slightly annoying, but I'd guess I'd be more willing to accept them if the ARK process would get more fine tuning to make things easier again for outsiders (I had hoped to contribute patches to help a bit with that, but never found the time :-/ ). My problem: with SRPMs it's easy to do this for thousands of packages in Fedora without known anything about the particular package: - verify the sources are pristine - update to a newer version - add or remove patches Kernel-ark broke all that from where I stand: - the sources included in kernel.spec don't match upstream and it's not obvious from reading the spec file how to verify them - if you want to manually update stable kernel.spec from say 5.16.5 to 5.16.6 you now have to modify the version number in iirc *four* different places; this like that would never pass a package review in Fedora. And even if you did that: then you still have to deal with the kabi stuff, which is not of interest for Fedora either iirc. - building a near vanilla kernel that still applied patches needed to get things things building (like the gcc12 patches in rawhide recently) used to be pretty easy, now it's hard (as can be seen by the mailing list post about this a few days ago; I had trouble as well, but was able to deal with them myself) There are likely other aspects that makes things hard for Neal. I guess with some more fine tuning things likely could be fixed or at least improved a lot. > I've somewhat > adapted to it, but I'm still not a fan of the process for the Fedora > kernel. I also don't like the implication that RHEL's needs are more > special in the Fedora kernel sources than any other downstream. > > And with the configs for kernel-ark, we call the RHEL configs as "ark" > instead of "rhel", which I think is weird and we should call it what > it is. And details like this IMHO really matter. For me they contribute to a slight "RH took over control and we can't do anything about this" feeling which makes me dislike the whole ARK approach, while I in reality like the idea as whole (especially if the process would be used for other packages as well). > Admittedly, I appreciate being able to adapt config differences > for them when working with ARK. > > There's a lot of other uncomfortable thoughts and questions that come > up when I think more about the Fedora kernel wrt workflow and > maintainer restrictions. For example, is it even possible anymore for > non-RH Fedora kernel maintainers? Was it ever really possible? These > are the kind of awkward questions that I don't know if I am going to > like the answer I get if I ask. > > If we're going to have RHEL configs in kernel-ark (remember, "ark" is > really "rhel"), would other downstream configs be allowed? Can the > testing apparatus be extended to build and test them? How far can we > go here? > > I have these questions as the CentOS Hyperscale SIG kernel maintainer > and as a general Fedora community member. > >> While there is a defined workflow, there are improvements being made >> over time, and we are still looking at places the current process can >> be improved. This is why the thread was started. Is the mailing list >> interaction where it should be from an automation point of view? Are >> we sending too much? Not enough? Not sure. I for one missed that you added patches to make gcc12 builds work. Did I miss them in the noise (then some tags might help to distinguish RHEL and Fedora specific stuff -- or do we have those?) or are those patches not mentioned on the list when they get applied (I would like that, but maybe that's just me)? > If I felt like the emails gave us something to do with it, I think I > would be okay with the emails. But I don't know what I'm supposed to > do with any of this. Yeah, sometimes they are kinda interesting, but at the same time I have a feeling that I lost track of what Fedora is doing due to the either the ARK process or all those mails reg RHEL specific things. Ciao, Thorsten _______________________________________________ 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
