Re: Announce: Linux-next (Or Andrew's dream :-))

[Linus Torvalds]

On Tue, 12 Feb 2008, Jeff Garzik wrote:

> David Miller wrote:
> > This is why, with the networking, we've just tossed all of the network
> > driver stuff in there too.  I can rebase freely, remove changesets,
> > rework them, etc. and this causes a very low amount of pain for Jeff
> > Garzik and John Linville.
> 
> Rebasing is always a pain, and John and I both agreed the other day that you
> do it too often.

I do think that some people rebase too often (and that David is in that 
number), often with no real discernible reason. I think rebasing is great 
when you are doing active development (ie you're really acting in "quilt 
mode") and I actually think git could and should integrate more of the 
queues modes, but I don't think it should be a default action for an 
up-stream developer.

I also don't think rebasing helps the particular problem under discussion 
(ie conflicts due to having to sort out dependencies between different 
trees), and in some ways hurts it.

One thing that I personally react to is that

 - I think sysfs and the device model layer has had too much churn, and 
   I'm unhappy that people seem to expect that to continue.

   [ NOTE!! I'm picking on the device model/sysfs stuff here not because 
     it's the only one, but because it's the obvious and good example. I 
     do think we have other cases of the same thing. ]

   Really. I do agree that we need to fix up bad designs, but I disagree 
   violently with the notion that this should be seen as some ongoing 
   thing. The API churn should absolutely *not* be seen as a constant 
   pain, and if it is (and it clearly is) then I think the people involved 
   should start off not by asking "how can we synchronize", but looking a 
   bit deeper and saying "what are we doing wrong?"

   It may well be that part of the problem is that the people causing the 
   churn don't realize the downsides of the pain they are causing, because 
   THEY aren't the generally ones that see it!

   For example, it's easy for Greg to change his driver core, and he can 
   obviously synchronize with himself in the other trees (because his left 
   hand is hopefully somewhat aware of what his right hand is doing), so I 
   suspect Greg simply doesn't see the pain that much. So Greg thinks that 
   the solution is to just have me merge his changes early, and the pain 
   is all gone as far as he is concerned.

 - That said, I'm also a bit unhappy about the fact you think all merging 
   has to go through my tree and has to be visible during the two-week 
   merge period. Quite frankly, I think that you guys could - and should - 
   just try to sort API changes out more actively against each other, and 
   if you can't, then that's a problem too.

   In other words, please do use the distributed nature of git to your 
   advantage, when there are things you guys know you need to sort out.

So there are two separate and totally independent issues here.

One is that I suspect some people are a bit too willing to do cleanup for 
its own sake, and do not realize that backwards compatibility does 
actually help too, and that "better solutions" are sometimes worse than 
"keep things stable". We should always *allow* major breakage when 
necessary, but I think the threshold for them should be higher than I 
think it currently is.

The other is that once somebody says "ok, I *really* need to cause this 
breakage, because there's a major bug or we need it for fundamental reason 
XYZ", then that person should

 (a) create a base tree with _just_ that fundamental infrastructure change,
     and make sure that base branch is so obviously good that there is no 
     question about merging it.

 (b) tell other people about the reason for the infrastructure change, and 
     simply allow others to merge it. You don't have to wait for *me* to 
     open the merge window, you need to make sure that the people that get 
     impacted most can continue development!

This is where "rebases really are bad" comes in. When the above sequence 
happens, the fundamental infrastructure change obviously does need to be 
solid and not shifting under from other people who end up merging it. I do 
not want to see five different copies of the fundamental change either 
because the original source fixed it up and rebased it, or because the 
people who merged it rebased _their_ trees and rebased the fundamental 
change in the process.

Can that (b) be my tree? Sure. That's been the common case, and I'll 
happily continue it, of course, so I'm not arguing for that to go away. 
Merging is my job, I'll do it. But when the merge window is a problem, my 
merge window should *not* hold up people from using the distributed nature 
of git for their advantage.

But yes, obviously when doing cross-merges, you'd better be really 
*really* sure that the base is solid and will get merged. But let's face 
it, all the really core maintainers should damn well know that by now: 
you've all worked with me for years, so you should be able to trivially be 
able to tell whether you *might* need to worry about something, and when 
it's a slam dunk.

And it's the "it's a slam dunk" cases that I think are (a) the common ones 
and (b) the ones where you can just do cross-merges to satisfy each others 
needs.

Hmm? Does that sound palatable to people?

			Linus
--
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/