On 20 Jan 15:23, redbaronbrowser via CentOS-devel wrote: > 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. Mike just told that they would change that. I am not saying the SIG is not worth it, but that first point could be mooed by red hat if they do it upstream. -- (o- Julien Pivotto //\ Config Management SIG V_/_ https://frama.link/cfgmgmt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210120/fa148748/attachment-0005.sig>