Thorsten Leemhuis <regressions@xxxxxxxxxxxxx> writes: > On 22.01.24 09:24, Kalle Valo wrote: >> "Linux regression tracking (Thorsten Leemhuis)" >> <regressions@xxxxxxxxxxxxx> writes: >> >>> FWIW, that usage was slightly off and not how it's supposed to be done. >>> But whatever, let's ignore that. I'm reworking things currently >>> slightly, as you are not the first one that slightly got mislead -- and >>> the newer commands will hopefully be mire intuitive. >> >> Just to educate myself, how should I have done it? (But feel free to >> skip the question if you are busy) > > I think that's not worth it, as I hope to introduce the new commands in > the near future (but you know how it is with the last 5 to 10 > percent...). I sure do know :) I assume you will announce in the regressions list once the new interface is available, I'll then take a look at it in detail and update my notes. > But let me show you how it's then supposed to be done in this > situation, that way you can give early feedback: > > #regzbot report: https://bugzilla.kernel.org/show_bug.cgi?id=218364 > #regzbot introduced: 0a3d898ee9a8 > > That "#regzbot report" will be new and make it more obvious to users > what regzbot should consider to be the report (e.g. what Link:/Closes: > tags later in commits fixing the issue will link to). Thanks, this looks very intuitive to me. > You used "#regzbot introduced: 0a3d898ee9a8 ^" and due to the "^" it > assumed the start of this thread would be the report Actually I did that on purpose as I wanted to test how including a mail to a regression report works :) > (side note: mixing that aspect into the "introduced" command was a > stupid idea anyway.). > > That "#regzbot link:" will vanish as well (at least from the docs, it > will remain to be supported), as people use it wrong in various > different ways: for duplicates, reports (like your did), patch > submissions fixing the issue (then 'regzbot monitor' should have been > used) among others. Which is totally understandable now that I look at > it. That's why it will be replaced by "#regzbot related: <url>" to avoid > any connection with the Link: tag used in commits; for duplicates > "#regzbot dup:" will stay around. So, in the new interface, how should I handle a situation that a regression is first reported on the mailing list, added to regzbot and later there's also a bug report opened for the issue? >> I wish there would be a person who could follow stable >> releases from wireless perspective and make sure everything is ok there. > > Maybe at some point regression tracking can help somewhat with that. But > I still have to fix a few things to make people use it and scale it up. I just feel it should be more than that, I'm worried that randomly taking wireless commits to stable releases is risky. There really should be someone looking after wireless (read: reviewing patches) in stable releases. This would be a good role for someone who is interested to learn how kernel.org development works and helping the community. Do we have a way to announce these kind volunteer vacancies somewhere? :) > Side note: some people seem to have gotten the impression that I care a > lot about *all* stable/longterm kernels. Let me use this opportunity to > say that it's not really the case. I fully understand and respect that > those series are a somewhat separate thing some developers don't want to > be involved in (especially the older trees). But the thing is: the > latest stable tree is what we tell users to use -- and something quite a > few important distros ship as their regular kernel these days. That's > why I take special care of regression that found there. Yeah, I understand that a lot of users use stable kernel releases. But the reality is that we in wireless really don't have the bandwidth to manage stable kernels, it is enough of a challenge to manage Linus' releases. So help here is very much needed. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
