On Wed, Feb 10, 2021, at 19:58, redbaronbrowser via CentOS-devel wrote: > On Wednesday, February 10, 2021 3:51 PM, Brian Stinson <brian at bstinson.com> wrote: > >> On Wed, Feb 10, 2021, at 13:17, redbaronbrowser via CentOS-devel wrote: >>> On Wednesday, January 20, 2021 9:31 AM, Mike McGrath <mmcgrath at redhat.com> wrote: >>> >>>> I've confirmed with the team, the git repo is going to be all the normal git patches you would expect (IE: not arbitrarily munged together in some way). There's one or two more things they're configuring with gitlab and they expect to have an actual repo that you can look at / poke at to validate what I'm saying in a few weeks. >>>> >>>> -Mike >>> >>> Mike, is there any status update on individual patches applied to Stream's kernel? >>> >>> Can we move forward with this SIG so I can publish the information I already have? >>> >>> What about a Stream Plus kernel? The directory for Stream still has no packages at all. >>> >>> Or delivering kpatch live security updates without a reboot? >>> >>> I am ready to move forward immediately if the SIG is approved. Is there a reason to wait another "few weeks"? >>> _______________________________________________ >>> CentOS-devel mailing list >>> CentOS-devel at centos.org >>> https://lists.centos.org/mailman/listinfo/centos-devel >>> >> >> I see your questions roughly grouped in 3 categories, correct me if I've misinterpreted: >> >> - How do I get patches into the Stream kernel *now*? >> Have you submitted any bugs against CentOS Stream on bugzilla.redhat.com with your patches? I want to make sure, first, that we have an actual answer because some of them may indeed be workable for inclusion in RHEL. > > Ok then. If I am ever talking about inclusion of new patches, I will consider doing that. > > Before contributing more patches to the tar-ball mess claiming to be "4.18.0," I would like to work with the Stream community on the information I have so far of code that doesn't exist in a true 4.18.0 kernel. I have a break down of chunks that are related to specific modular patches but not publicly documented as such. Let's see what you have! I'm curious to take a look > >> All contributions for RHEL/Stream 8 (not just the kernel) are flowing through this bugzilla process for right now. > > Yes, I have already figured out that the designation of Stream being an "upstream" has changed nothing on how others contribute yet. There really is no need to rub it in our faces. I already get it. > > To be meaningful members of an "upstream" we need to get things documented like an upstream. I have already been working on the documentation that RH/RHEL can't by policy make available even after the request to wait "a few weeks." > >> - When can we see the new kernel workflows? >> I don't have specific date/time when we expect to see the new-way of doing kernel repos but I would check https://gitlab.com/redhat/ towards the end of the month. Those will be targeted at RHEL/Stream 9 kernels. I'm asking around about some of the work we're doing to make the Stream 8 kernel sources more accessible in a format that isn't just tarballs. > > End of February isn't just "a few weeks" after Jan 20th, it is over an entire month. > > I also don't care about Stream 9 right now. Stream 8 kernel is in serious need to being better documented. We were told back in December by a number of Red Hat employees we had been given enough information to decide for ourselves what we want to do. We were also told that Stream was to enable us more power to contribute and RH wants to see what SIGs the community would like to create. This is the most glaring area of needed help. There was nothing available reasonably documenting the Stream 8 kernel. There was no Stream 9 kernel available or any ETA given to one coming. I have focused for over a month in documenting what Red Hat fail to. > > Mike indicated to just wait "a few weeks" and we would see it available in some official way. It has been a few week and there is nothing. It is not clear if we see something at the beginning of March or if there will be additional reasons it won't be til April. It isn't clear if some git commits lumped multiple unrelated code into the same commit. It isn't even clear if we will ever get a break down of the Stream 8 kernel. But it doesn't matter, I have done the work that needs to be done and am requesting now to have someplace to post it. What form does your work take currently? Are you thinking a git repo? Individual patch files? documents? > >> - How do I get kernels that are not shipped in-distro? >> Here's the problem as it exists right now, Kernels typically need secureboot signatures on them, and we don't have the infrastructure we need to make those signatures happen in the community build system. We're talking about ways to enable that directly in CBS, but in the meantime we plan to take community-based kernels and assist with getting builds done on infrastructure that can do signing. Note: this affects other packages like fwupd, grub, etc. We are absolutely open to continuing to build the Plus kernel. Would it make sense to get yourself, @toracat for the Plus kernel, and whoever else is interested in building kernels together on IRC to talk about how to handle coordination here? > > I would like to get started now. If that means we need documentation explaining how to turn off Secure Boot or how to register a self-signed key into Secure Boot, I will do that. But there is no reason this needs to be an all or nothing. Withholding 100% of everything on the progress of Stream 8 Plus until it is ready to ship to general users is not the way for Stream to achieve being more "open" than CentOS 8. It is how Stream 8 is even that much more closed than the CentOS 8 which already has a Plus kernel available. > >> With regard to distributing kpatch updates, I'd advise caution here. I get the sense that there may be problems building and testing all of the combinations of kpatches that a SIG might want to ship. > > I have no interest in contributing to something were the need is the least. I want to make progress on what needs the most work. It is understandable that SIG will be working for months before having anything to ship. But if Stream is the "upstream," why isn't the community involved in the process over those months? > >> Let me know if there's anything else I can help with. > > I don't know. It seem like we don't even have a common ground on what Stream being an upstream even means. > > There is no interest on my part of being Steve Jobs and presenting a finished product. Instead it is my hope to be part of the team that works on the "and another things." To me going from the downstream to the upstream puts the type of related SIGs to be under the moto of "release early, release often." You are calling for caution because being an upstream SIG means things will be messy? Let it be messy! Otherwise what is the point? I think we might have more common ground than you think. The kernel and a handful of other packages are special related to the infrastructure needed to build them, and I'm wanting to work out a way to help fill that need while we work on permanent solutions. I'm planning on hanging out in #centos-stream on Freenode this Friday at 14 UTC and then again at 20:30 UTC specifically to talk about kernels, and how the Stream infra team might help. Anyone is invited! If those times don't work we can keep chatting here and find another time that does work. > > What this SIG purposal is *NOT* and never will be is advise for people to sit on bugzilla and IRC waiting for the beginning of March to see if it is an ETA to another ETA. It is intended to be messy in February, March, April and all of the other months of 2020 to get progress done completely in the open with others than want to get messy. > > If you get over your mysophobia (fear of dirt), then we can better talk about how you can help. > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > --Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210210/9cab8aa1/attachment-0005.html>