[CentOS-devel] RFC: Stream Kernel SIG Proposal

redbaronbrowser

redbaronbrowser at protonmail.com
Wed Jan 20 15:23:15 UTC 2021


On Wednesday, January 20, 2021 7:06 AM, Mike McGrath <mmcgrath at redhat.com> wrote:

> On Wed, Jan 20, 2021 at 2:51 AM Phil Perry <pperry at elrepo.org> wrote:
>
> > On 20/01/2021 08:12, Julien Pivotto wrote:
> > > On 20 Jan 08:08, redbaronbrowser via CentOS-devel wrote:
> > >> There are four main goals of this SIG:
> > >>
> > >> First, break down changes in the Stream version 4.18.0 kernel into individual patches.  When possible, document the source the patch is from and the purpose of the patch.  Moving forward also document which Stream kernel package revision introduced the patch.
> > >
> > > Let's face it that should be the sane technical default for stream, from
> > > red hat. They should provide it out of the box. What they do downstream
> > > after this is up to them.
> > >
> > >
> >
> > Agreed. I makes it very very difficult to contribute to Stream at the
> > kernel level is any meaningful way if there is not a proper git
> > repository (or similar) tracking all commits that have been made over
> > the lifetime of the project.
> >
> > Red Hat killed CentOS Linux on the basis it's community was simply a
> > community of users and didn't contribute anything. As it stands CentOS
> > Stream is no different as there is still no effective way to contribute.
> > Having a proper git repository is the first step to changing that.
> > Otherwise we are shackled to remaining users who can file bug reports
> > when something breaks but little else.
> >
> > In reality, Stream is not an open upstream of RHEL, but rather CentOS
> > and RHEL have simply switched positions within a closed downstream
> > process, CentOS Stream now being the first (development) step in that
> > closed process rather than a rebuild of it.
> >
> > I'm not offering to be a part of this proposed SIG, but am watching the
> > whole topic with much interest.
>
> I'll check with the kernel team and see if we have any published plans or even a test repo we can share so people can see what we're planning.

I'm sorry for the confusion but I want to make clear this SIG does not depend on any changes on the part of Red Hat.  They are welcome to contribute if they can do so in a meaningful way but I don't want this SIG purposal refused on a misconception this is an attempt to change Red Hat's policy not releasing the details of their obfuscared kernel themselves.

You had said on the mailing list on Dec 25th: "We want a robust SIG community, and that includes welcoming things that Red Hat isn't particularly interested in."

I am trying to do exactly what you indicated CentOS is interested in. I brought up the issue with the openness gap with the kernel several time perviously and Red Hat showed they were not particularly interested in addressing it.

I would also like to point out that the types of errors I am getting when trying Stream falls short of Q/A testing required of a Fedora release.  There are some bugs am I seeing that Fedora would treat as release blockers and what I am seeing could not pass a Fedora Go / No-Go release meeting.

At the same time, it has been made clear on the mailing list that Red Hat does not consider this to be another Rawhide or Beta release.  Given Red Hat consider this production quality while falling short of Fedora standards, it seem clear at this point Red Hat is incompetent in performing Fedora-grade testing and fixing Stream is being left up to the community.

With that in mind, the place I need to start is at the kernel.  It has a higher level of priviledge than any other part of Stream.  It also is the only part that normally requires a full reboot of the hardware to put an update into actual use.

So, again, Goal #1 is already being worked on.  It is just a matter of it is published as part of Stream or as part of a fork of CentOS.  If Red Hat is welcoming of things it isn't particularly interested in, then it shouldn't be a problem to work on this as a CentOS SIG.

I was really hoping to get feedback about the other three goals instead of remaining stuck on just one specific goal.  Is no one interested in any of the other three goals?


More information about the CentOS-devel mailing list