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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Feb 2008 10:48:38 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	Jeff Garzik <jeff@...zik.org>, David Miller <davem@...emloft.net>,
	arjan@...radead.org, greg@...ah.com, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/