[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMuHMdXoVzcVERZQXDYxDZZc2_=huaAF8dC8o4iksV07w8ZU7Q@mail.gmail.com>
Date: Wed, 17 Aug 2022 16:41:18 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: stats (Was: Linux 6.0-rc1)
Hi Stephen,
On Mon, Aug 15, 2022 at 4:55 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> There are also 320 commits in next-20220802 that didn't make it into
> v6.0-rc1.
> Top ten commiters:
> 13 geert+renesas@...der.be
How did that happen? Turns out these are false positives.
Whenever I update any of the renesas-*-for-vX.Y branches, I merge
them into renesas-next, which is pulled into linux-next.
When a commit in a renesas-*-for-vX.Y branch turns out to be bad,
and the branch hasn't been pulled by soc yet, I just fix that by
rebasing the renesas-*-for-vX.Y branch, and resolving any conflicts
during the next merge into renesas-next.
So the bad commits are gone from the renesas-*-for-vX.Y branches,
and thus will never go upstream, but technically, they are still part
of linux-next. Hence they show up in the statistics you do not
want to be part of...
Perhaps I should just recreate renesas-next every time any of the
renesas-*-for-vX.Y branches needs to be rebased? I already recreate
renesas-next after each rc1 release.
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
Powered by blists - more mailing lists