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

[Luck, Tony]

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/