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

Linus Torvalds
2008-02-12T18:49:49Z

On Tue, 12 Feb 2008, James Bottomley wrote:
>
> Hm ... I think net is a counter example to this. Rebases certainly work
> for them.

They consider themselves to be "one tree" and are thus largely a totally
different issue than the one discussed here.

Also, I actually flamed David a lot last round over his rebasing of
netfilter etc. It was no acceptably done. That network tree was all
screwed up, with the git committer information not matching the signed-off
path etc.

If you do cross-tree rebasing, you need to consider it 100% equivalent to
just passing patches around in emails. Because it really is.

> Yes ... I don't do that ... Like I said, I only rebase for an actual
> conflict.

And this is how things should work.

> Well, it came at me because Jens was rebasing the block tree as he
> worked through issues in the two branches I was based on.

Yes, and I am in no way saying that the core driver model has been the
only problem spot.

And also, I do not like "hard rules". Every rule always has an exception,
and sometimes a rebase-based strategy can be the right thing even across
trees.

But you're all ignoring my fundamental objection: you're talking as if
cross-tree fundamental API changes should be the "norm", and that we
should try to solve the workflow issues that stem from that. And I'm
saying that I think we should try to FIX the issue, and make sure that
it simply *isn't* the norm.

In other words, I'm perfectly happy to be an a*hole and tell people that I
simply won't merge things that cause undue API churn at all, and that were
not thought out sufficiently.

We've had too many issues like that (SG chaining, iommu, driver core, not
to mention the upheavals in x86) lately, but realistically, which
subsystem remains a problem for the future? And maybe the correct thing to
do is to just say "enough!".

I'm perfectly happy being hardnosed and saying "nope, that's crap, it
doesn't matter if the code is slightly better if you cause those kinds of
issues".

The thing is, sometimes the answer really *is* "Don't do that then!". If
our model becomes bogged up by cross-subsystem serialization issues, that
means that we (a) spend too much time handling the fall-out from that and
(b) too little time just refining the details.

And quite frankly, while "good core architecture" matters a lot, in the
end, "getting all the boring small things right" matters even more! Big
architectural churn that cleans up and fixes the "big issues" is totally
anti-productive if it means that we don't look at the boring small detail
stuff.

Linus