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

[Luck, Tony]

> > This is why I suggested that "-rc5" should be declared as the rebase
> > deadline for trees feeding into linux-next ... and that maintainers
> > should be ENCOURAGED TO REBASE for any issue where it makes sense.
> > 
>
> We used to do that in -tip, and Linus ripped us a new **** for it.

It would be good to poke Linus a bit more on why ... I think there are
some clear areas where rebasing makes sense. E.g. a topic branch with
a bug in one of the early commits in the series.  I don't see what
value there is in that being merged upstream as:

 p1 .. p2 .. BUG .. p4 .. p5 .. p6 .. FIX
rather than:
 p1 .. p2 .. p3' .. p4 .. p5 .. p6

so long as this rebase is done a reasonable amount of time (and
I'm saying that 2 weeks is reasonable) prior to the "please pull".

If someone submitted a seven part patch series with a BUG and
following FIX ... you'd tell them to merge the FIX into the
earlier patch and re-submit! So why do we think it reasonable
to take a six part patch series that is later found to have a
bug, add the Band-Aid to the top of the series and push the whole
mess to Linus?

Maybe we need a Documentation/rebasing.txt that gives some better
guidelines on when a rebase is evil (just moving the anchor point
to somewhere different an hour before the "please pull"), and when
they are not only allowed, but actively the right thing to do (my
example above).

-Tony