[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <409a039b-fd00-a480-ee82-e7a329fa7ae2@leemhuis.info>
Date: Tue, 4 Oct 2022 12:16:22 +0200
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Slade Watkins <srw@...dewatkins.net>,
Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
"Artem S. Tashkinov" <aros@....com>, workflows@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
ksummit@...ts.linux.dev
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
blues"
On 04.10.22 11:20, Geert Uytterhoeven wrote:
> Hi Thorsten,
>
> On Tue, Oct 4, 2022 at 10:41 AM Thorsten Leemhuis <linux@...mhuis.info> wrote:
>> But I consider explaining things like bisection and localmodconfig in
>> the documentation as also important, as that's likely something the tool
>> won't be able to automate any time soon (or never, as realizing that is
>> likely hard and better left to a separate tool anyway).
>
> Creating a simple Linux-specific wrapper around git bisect under
> scripts/ might be useful?
> The wrapper could copy .config to
> $(srctree)/arch/$(ARCH)/config/bisect_defconfig, automatically run
> "make bisect_defconfig" in each step, and show not only the bisected
> commit, but also the impact on .config.
Don't worry, I still remember that trick of yours from this discussion:
https://lore.kernel.org/all/12e09497-a848-b767-88f4-7dabd8360c5e@leemhuis.info/
Something like that would be a start, but I'd say having localmodconfig
covered would be wise also, as it speeds things up tremendously for
those that start with a full-blown x86 pc distro config.
There are also people that find regressions when updating from say
v5.18.15 to v5.19.4 and want to bisect that range; never tried if that
actually works with a stable git tree, but I'd assume that approach is
unwise. I also assume a lot of people would prefer to download only the
recent history or specific stable branches when cloning the git tree
(which is possible if you know what to do, but I guess most people don't).
Ciao, Thorsten
Powered by blists - more mailing lists