On Tue, Jun 16, 2020 at 6:39 AM Jóhann B. Guðmundsson <johannbg@xxxxxxxxx> wrote: > > 2On 16.6.2020 10:43, Peter Robinson wrote: > >> I'm not seeing any kernel 5.7.1, 5.7.2 kernel builds in koji and on it's > >> way to <=33 now after 5.7.1 had been released ( expected after 5.7.1, > >> there are two weeks since last 5.7.x build ) is that part of this new > >> workflow along with this significant CI noise and needless one line ack > > Nothing at all related to it what so ever. The standard process for > > new stable kernels in Fedora stable releases has been "sometime after > > the .3 release" and has been that as long as I've been involved in > > kernel stuff (about 10 years). > > You might want to update [1] to reflect what is written since as I > recall for over a decade this has always been more or less the case ( or > atleast the aim ). > > "For stable Fedora branches, the updates essentially follow the upstream > stable release schedule. Those tend to be released once a week or > slightly less frequently. We do the minor update, build and submit, > making sure that the N-1 update is in stable before pushing that release > (unless N-1 is very broken.) E.g. When 3.19.2 is released, we push it to > testing and make sure 3.19.1 is at least queued for stable. That way > bodhi doesn't obsolete the 3.19.1 update. When we have a major rebase > for a stable Fedora branch, we follow the same guidelines as above but > simply allow more time for people to test." > I will admit, I do a poor job of keeping documentation updated, but I will try to break it down as well as I can. Way back when, probably 5 or more years ago now, upstream stable had a practice of not even doing .1 until after the merge window. When that was the case, our aim was the first stable rebases would be on .2 or .3. For the past several years though, this is not the case. Now that .1 is happening fairly early in the merge window, rebases tend to happen at .5, give or take. Now you may look at koji and see that there were .2 or .3 and .4 builds happening against the stable branch, and that is true, but they were not submitted to bodhi. I have started doing those for the sole purpose of getting secure boot signed kernels to be used for kernel test week. The 5.6.1/2/3/4/5 kernels that you see in bodhi are against F32, which was not released yet, and was following 5.6 from the merge window. 5.5.18 was the last 5.5 kernel built for F31, and 5.6.6 was the first rebase kernel for F31. When things do not line up with a development release of Fedora, such as now, I put stable kernel source updates into the stabilization branch, and I try to build them in the kernel-stabilization copr. None of this has anything to do with ARK, ELN, or anything else. The timing has been pretty similar for over a decade here, only the version numbers have changed because of upstream doing stable .1 and usually .2 during the merge window. There was a *slight* timing change, almost 2 years ago at this point when I went from doing a single day "kernel test day" to a full week. This delays the rebase attempt by a couple of days, but allows for more testing, so that the rebase kernel is more likely to be in good enough shape to push. > > > The process for stable lands the new kernel into the stabilization in > > dist-git, and 5.7.2 has been there since Wed 10th, from there the > > various maintainers check it's ready and then a test week is scheduled > > and initial builds are done. > > > > The process is unchanged by any of the changes for the rawhide kernel > > building which has the new process. Justin is on PTO this week, later > > this week upstream will no doubt do a 5.7.3 release and I suspect next > > week there will be a test day. > I am still doing daily rawhide builds, will be doing stable updates and security updates as they are needed, and yes, 5.7 test week is scheduled for next week, I will have images built and ready for that with the most recent 5.7 stable kernels. > Who's his backup ( please tell me he has a backup ) and what's she/he doing? > Jeremy switching focus has been really recent, and I have been training 2 of the RHEL kernel maintainers to take over as a backup should I take PTO/get sick/get hit by a bus. But the merge window put a hold on getting everything ready for them to be able to step in this week, and as a result I am working as needed. But I am doing it with a nice view of the ocean :) > > > >> messages on what was otherwise a mailinglist in which people could have > >> meaningful discussions ( as of today 41 messages of pure noise until you > >> reach Justin Forbes "Re: Streamlining the ARK config process" )? > > As one of the community kernel maintainers doing a bunch of the arm > > related kernel stuff in my own time I am actually just fine with the > > the messages, the increase in actively is larger than the very quiet > > kernel list before but it's still completely manageable and with > > headers etc the messages are very easily filtered if you don't like > > them. > > Where do you draw the line what is manageable and what is not 5 mails > per day 10,100? > > So you are suggesting people workaround the problem by now adding filter > rules to circumvent this noise instead of it simply be directed to a > separated ML in which people could simply subscribe to if it wished for > CI noise? > The noise is particularly heavy during the merge window, and fairly low otherwise. The end result though, should be a more open kernel maintenance process, and a benefit for both Fedora and RHEL. > >> Did not the RH management that conducted this takeover of the Fedora > >> kernel process even consider creating a separated mailinglist ( > >> kernel-ci, kernel-build whatever ) when it started projecting it's > >> internal spaghetti mess of process,workflows and cluttered pipelines > >> onto the community? > > Well as far as I'm aware "RH management" had nothing to do with the > > change of process and it came directly from the actual kernel > > maintainers both in Fedora and Red Hat. It will in the medium term > > allow the wider community have a say and more of an impact as to what > > RHEL kernels look like and opens up the process more, with my > > community maintainer hat on (and I really have zero to do with the > > internal RHEL kernel process) I actively welcome this. > > Red Hat should be listening to and serving it's customers and adhere to > it's customers needs not Fedora so I dont see how the wider community ( > whatever that means presumably the Fedora community ) wants to have any > saying in anything RHEL related kernel or otherwise nor would I expect > RH to allow the Fedora community dictate and decide it's business > strategy and what actually gets pushed by RH no more than it has done in > the past so could you explain to me what benefits the *Fedora* ( not > RHEL not CentOS not whatever else ) community is supposed gain from this > since I fail to see what those benefits are supposed to be. > RHEL has kernel developers and engineers in every subsystem of the kernel. I am very much a generalist, and while I think I have a decent understanding of things, I am very happy to see feedback from specific expertise in the new things that are coming upstream. If the price for that is a few more emails which really are not relevant to Fedora, I believe it to be very much worth the cost. I am 100% dedicated to Fedora, and I would be pushing back heavily if I didn't believe that Fedora was getting some benefit from this process. There is some pain point in the transition, but I do believe it will be worthwhile once the dust settles. Justin _______________________________________________ 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
