linux-kernel - Re: Please pull ACPI updates

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:	Thu, 17 Jul 2008 08:47:43 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, torvalds@...uxfoundation.org,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: Please pull ACPI updates

On Thu, 17 Jul 2008, Linus Torvalds wrote:
> 
> That's the whole point of topic branches. They allow you to separate out 
> work to different areas, so that people who are interested in (say) the 
> PCI-impacting ones can merge with one part, without having to wait for the 
> other parts to stabilize.

Btw, you don't really have to have a lot of them.

When it comes to ACPI in particular, I would really prefer to see at least 
the ACPICA stuff in a separate topic branch. It comes in from a different 
source, it's maintained separately, and when it causes problems(*) it ends 
up usually being handled differently too.

Len additionally split things like bugzilla entries up into individual 
topics, and that was really nice to see when merging, but I have to say 
that it was also "above and beyond" what I've ever expected of any 
maintainer. That said, I think ACPI has been rather bugzilla-driven (many 
other areas are feature-driven), and I do think it makes tons of sense to 
put fixes in different branches, and then you can merge them when you 
actualyl close the bug when the fix has been verified.

So one reason I reacted strongly to the ACPI change was definitely just 
that ACPI used to be one of the really nicely done subsystems (not just 
from a git standpoint, but the whole git flow was part of it). There were 
some issues very early on in git usage, but I gave a shout-out to Len at 
the last kernel summit for a reason.

And in that sense it's definitely unfair to require quite _that_ level of 
separation. I'm really not expecting it. 

But I *really* hate pulling from somebody, and seeing commit dates that 
are from five minutes ago, and based on something that I had just pushed 
out (which was essentially the case for this round of ACPI changes).

That literally shows that the code was hardly tested _at_all_ in that 
exact configuration. It may have gotten testing based on some earlier 
kernel version, but then it very clearly got rebased (or just quilt 
imported) on top of a totally new kernel base, and was not tested in that 
version very much if at all.

So even if you end up using quilt, I'd suggest you do so on a specific 
base, rather than on some random "kernel-of-the-moment-in-the-middle- 
of-the-merge-window". Because then at least I feel like the people 
involved have been doing their own development without having the rug 
pulled out from them all the time by using a different kernel as a base.

		Linus

(*) Which is happily fairly rare these days! I obviously detest the 
complexity that is ACPI, but even if I detest it, Intel should get cudos 
for getting it to work.
--
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/