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

Steven Rostedt rostedt at goodmis.org
Thu Jun 21 12:05:40 UTC 2012


On Wed, 2012-06-20 at 17:21 -0700, H. Peter Anvin wrote:
> On 06/20/2012 02:42 PM, Luck, Tony wrote:
> >>> 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 ...
> 
> Linus made it very clear why: he wants the branch to reflect its
> development and testing history.

I thought his rational was more about workflow than keeping development
history. He may have said that was a plus, but I can't see him pushing
the no rebase policy so hard just to keep development history. As he has
publicly said several times that it is fine to rebase your local
repositories, but once it becomes public don't.

If he wanted development history so badly, I would think he wouldn't
want you to rebase your local repos.

The problem with rebasing a public repo, and more specifically, one that
others develop against (like Linus's own repo and tip), is that it
screws up everyone that develops against it.

When tip use to rebase (a long time ago), it screwed up my work flow.
I'd be working on code based on some code that I already had pushed to
tip. Then when I get ready for another push, I would see that it was
rebased, along with half my changes I had previously pushed, and I
didn't know what was in tip and what wasn't.

I had to rebase on top of tip to clear that up, but I still couldn't be
sure if what I pushed out stayed the same or something strange happened
in a rebase. Linus has said that once you rebase, its like that code has
never been tested.

I agree with Linus that a repo that is being used by others as a base
should not be rebased. But I disagree with him if you have a repo that
just pulls in others work, but is not suppose to be the base of anyone's
work. There should be no reason to not rebase that kind of repo.

This is really why I find no harm in rebasing linux-next, as people
should only be using linux-next to see if their code works fine with it
or not, and they should not be developing against it. But there should
be a time frame that linux-next should not be rebased to cover
'testing'. And even if a bug is found then, it should just be fixed
without a rebase, as this code is getting ready for mainline. If you
think a rebase is better, then pull it out of linux-next and pass up the
coming merge window.

If you do develop against linux next, then just cherry-pick your changes
to a stable repo and push that. That should also work fine.


> 
> This is a policy decision on Linus' part; one can go either way for
> valid reasons but Linus has made it perfectly clear that preserving
> history beats bisectability.

I believe that we can persuade Linus to accept rebasing a repo that is
not the base of others work but only for testing integration (like
tip/master does).


-- Steve

> 
> This is a policy decision on Linus' part; one can go either way for
> valid reasons but Linus has made it perfectly clear that preserving
> history beats bisectability.
> 
> 	-hpa
> 




More information about the Ksummit-2012-discuss mailing list