On Fri, Feb 11, 2022 at 11:25 AM Justin Forbes <jforbes(a)redhat.com> wrote:
On Fri, Feb 11, 2022 at 8:07 AM Thorsten Leemhuis <fedora(a)leemhuis.info> 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!