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