All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Pavel Machek <pavel@ucw.cz>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: A note on the 5.12-rc1 tag
Date: Sat, 6 Mar 2021 13:54:37 +0100	[thread overview]
Message-ID: <20210306125437.GA436274@gmail.com> (raw)
In-Reply-To: <CAHk-=wgZjJ89jeH72TC3i6N+z9WEY=3ysp8zR9naRUcSqcAvTA@mail.gmail.com>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> But I also can heartily just recommend that people who already _did_
> start on rc1 to rebase their current - hopefully not extensive - work.

Thanks for the heads-up - we just rebased about 50 commits in -tip to 
avoid this bug: our normal workflow is to jump on -rc1 once it's 
released and integrate pending development work that we normally don't 
apply during the merge window. So our special pattern of pent-up 
merging did bite us a little bit - but nothing particularly serious.

> I know I've ranted about rebasing for years, and it has huge 
> downsides, but the operation does exist because sometimes you just 
> need to fix serious errors. So _mindful_ rebasing, understanding why 
> it shouldn't be a normal thing, but doing it when something 
> exceptional happens - that's not wrong.

Yeah, and in this case not sending scarce-resource testers & bisecters 
into the middle of a file corruption bug is definitely the right thing 
to do.

Maybe -next could double check that none of the maintainer trees have 
an -rc1 base? Your note here was kind of low-key. :-)

And maybe there's some bisection helper annotation or hook-script that 
can be embedded in the kernel Git tree to avoid or at least warn about 
particularly nasty bugs?

Thanks,

	Ingo

  reply	other threads:[~2021-03-06 12:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03 20:53 A note on the 5.12-rc1 tag Linus Torvalds
2021-03-04 12:43 ` Pavel Machek
2021-03-04 13:23   ` Krzysztof Kozlowski
2021-03-04 17:57   ` Linus Torvalds
2021-03-06 12:54     ` Ingo Molnar [this message]
2021-03-04 15:00 ` Geert Uytterhoeven
2021-03-04 16:56   ` David Laight
2021-03-04 18:58     ` Geert Uytterhoeven
2021-03-05  9:14       ` David Laight
2021-03-04 20:51 ` Josh Triplett
2021-03-05  5:39   ` Christian Couder
2021-03-05 18:10     ` Junio C Hamano
2021-03-05 23:06       ` Josh Triplett
2021-03-05 23:38         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210306125437.GA436274@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=sfr@canb.auug.org.au \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.