linux-kernel - RE: [RFC] to rebase or not to rebase on linux-next

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: 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" <tony.luck@...el.com>
To:	Theodore Tso <tytso@....edu>, Ingo Molnar <mingo@...e.hu>
CC:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Nicolas Pitre <nico@...xnic.net>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	"Luis R. Rodriguez" <mcgrof@...il.com>,
	Jeff Garzik <jeff@...zik.org>,
	Robert Richter <robert.richter@....com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
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.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/