From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
torvalds@linuxfoundation.org, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org
Subject: Re: Please pull ACPI updates
Date: Thu, 17 Jul 2008 08:47:43 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0807170835320.2959@woody.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0807170807040.2959@woody.linux-foundation.org>
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.
next prev parent reply other threads:[~2008-07-17 15:48 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-16 21:45 Andi Kleen
2008-07-16 22:11 ` Rafael J. Wysocki
2008-07-16 23:33 ` Jesse Barnes
2008-07-16 23:45 ` Linus Torvalds
2008-07-16 23:51 ` Jesse Barnes
2008-07-17 0:32 ` Linus Torvalds
2008-07-17 0:53 ` Linus Torvalds
2008-07-17 2:26 ` Jesse Barnes
2008-07-17 2:56 ` Linus Torvalds
2008-07-17 6:45 ` Andi Kleen
2008-07-17 15:06 ` Linus Torvalds
2008-07-17 6:40 ` Andi Kleen
2008-07-17 15:03 ` Linus Torvalds
2008-07-17 18:49 ` Len Brown
2008-07-17 19:12 ` Harvey Harrison
2008-07-17 19:50 ` Andi Kleen
2008-07-17 19:12 ` Linus Torvalds
2008-07-17 19:16 ` Linus Torvalds
2008-07-17 21:15 ` J. Bruce Fields
2008-07-17 23:11 ` [PATCH] Revert duplicate "dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled" commit (was: Please pull ACPI updates) Thomas Gleixner
2008-07-17 23:25 ` [PATCH] Revert duplicate "dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled" commit Andi Kleen
2008-07-18 0:07 ` [PATCH] Revert duplicate "ACPI: don't walk tables if ACPI was disabled" commit (was: Please pull ACPI updates) Thomas Gleixner
2008-07-17 6:47 ` Please pull ACPI updates Andi Kleen
2008-07-17 15:18 ` Linus Torvalds
2008-07-17 15:47 ` Linus Torvalds [this message]
2008-07-17 16:02 ` Linus Torvalds
2008-07-17 16:23 ` Andi Kleen
2008-07-17 19:11 ` Ray Lee
2008-07-17 19:49 ` Andi Kleen
2008-07-17 20:01 ` Linus Torvalds
2008-07-17 20:14 ` Andi Kleen
2008-07-17 20:16 ` Linus Torvalds
2008-07-17 20:28 ` Linus Torvalds
2008-07-18 13:25 ` Olivier Galibert
2008-07-18 15:57 ` Ray Lee
2008-07-17 20:34 ` Andi Kleen
2008-07-17 20:11 ` Ray Lee
2008-07-17 20:29 ` Andi Kleen
2008-07-18 6:39 ` david
2008-07-24 20:36 Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.1.10.0807170835320.2959@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=torvalds@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®