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: > > > > [sending this a second time with a different "From" address to get it on > > the list; sorry!] > > > > Lo! > > > > 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. 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. 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. > On the other hand, the workflow changes have certainly made the Fedora kernel more difficult for outsiders to work with. 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. 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? > 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
