[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

[Stephen Warren]

On 06/21/2012 10:14 AM, Luck, Tony wrote:
>> The other thing Linus always says on this issue is that it discards data
>> about where the changes were actually tested.  Mostly that shouldn't
>> matter but sometimes it might.
> 
> In the case where the changes had a bug, does it really matter where
> those changes were tested? What will go upstream is something different
> (changeset + a bugfix tacked on the top). So I can't see how knowing that
> the buggy version was tested for N weeks at a particular starting SHA1
> helps at all.
> 
> If the rebase just fixed a spelling error in a comment, or in the commit
> message ... and you rebase the patchset on top of some different point
> in the git history ... then I see how history of testing is lost.
> 
> I do concede Stephen Rothwell's point that rebasing causes problems for
> other trees that pulled from a tree.

But are other trees supposed to be pulling from them without co-ordination?

I guess there are two different cases:

1) Another Linux subsystem maintainer needs to pull in changes from
another subsystem to resolve dependencies. This definitely should
require co-ordination, if for nothing else than courtesy.

With an absolutely strict no-rebasing rule, just pulling in other
branches might be safe. However, in the absence of that, the owner of
the pulled branch has to be able to 100% guarantee that it won't be
rebased once it's included elsewhere. Currently, that guarantee is done
my manual agreement in specific cases.

2) "Random" people developing on top of a subsystem. This of course
needs to happen with no co-ordination; that's kinda the point of
distributed development and git. However, what's the difference between
requiring people to:

git rebase foo/branch
v.s.
git rebase foo/branch previous-head-of-foo/branch

Since I tend to base my local work on linux-next anyway (due to my work
often touching multiple subsystems), I always use the second command
above anyway. git makes this work really well. That said, perhaps people
dislike that workflow?