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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 25 Oct 2009 21:53:41 -0700
From:	"Luck, Tony" <>
To:	Theodore Tso <>, Ingo Molnar <>
CC:	Steven Rostedt <>,
	LKML <>,
	Nicolas Pitre <>,
	Stephen Rothwell <>,
	"Luis R. Rodriguez" <>,
	Jeff Garzik <>,
	Robert Richter <>,
	Dmitry Torokhov <>,
	Jean Delvare <>,
	Linus Torvalds <>
Subject: RE: [RFC] to rebase or not to rebase on linux-next

> 2) There are many legitimate reasons for "rewinding".  In addition to
> being able to add credit for tested-by and acked-by lines, sometimes
> patches are subtle.  More than once, patches have been sitting in the
> ext4 tree that have passed the XFSQA test, and thus have been "unit
> tested", but they still have bugs; in some cases, subtle bugs.  In
> some cases, bugs that cause data corruption.  In the case where the
> patches have hit linux-next, but the merge window hasn't opened yet, I
> prefer to fix the patch by mutating it, and rewinding the ext4 tree,
> instead of adding a fix later.  It makes it easier to cherry pick
> patches to the stable tree later, and it keeps the ext4 tree clean,
> and it has no downside in terms of linux-next --- see (1) above.

If the "rewind" is simply to add "signed-off-by" notations, update
commit comments (or code comments) ... then it does seem useful to
keep the commit chain anchored to the original commit, as the testing
that has been done is all still valid.

But as soon as you talk about fixing bugs ... then you ought to
just do a "rebase".  The code you are adding has changed, so it is
incorrect to preserve the illusion that these changes have had
extensive testing against the old commit base.  The code has changed,
so the testing clock gets reset to zero.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists