linux-kernel - Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 4 Oct 2022 12:45:03 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Thorsten Leemhuis <linux@...mhuis.info>
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"

Hi Thorsten,

On Tue, Oct 4, 2022 at 12:16 PM Thorsten Leemhuis <linux@...mhuis.info> wrote:
> On 04.10.22 11:20, Geert Uytterhoeven wrote:
> > 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/

OK ;-)

> 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.

That's not that much different, as you only need to run "make localmodconfig"
once, as the first step (or as step zero, before starting the bisection).

> 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

Yeah, you may run into issues that are fixed in v5.18.15, but not in
v5.18 itself, or in later intermediate steps.
For a short range like v5.18.15 to v5.19.4 (which are not LTS, hence
didn't receive that many updates, which can be good or bad), I don't
expect many problems, though

There are similar (but much worse) issues with bisecting between two
linux-next releases.

> 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).

Does it really save that much bandwidth?
How many minutes of 4K streaming video is the kernel nowadays? ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds