Temporary ACPI maintainer for this summer - Kernel

This is a discussion on Temporary ACPI maintainer for this summer - Kernel ; Len Brown is on sabbatical from Intel this summer. While he's away I'm serving as the temporary ACPI maintainer. Please send all ACPI mails and patches you would normally send to Len to me, ideally cc linux-acpi@vger.kernel.org . As usual ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Temporary ACPI maintainer for this summer

  1. Temporary ACPI maintainer for this summer


    Len Brown is on sabbatical from Intel this summer. While he's away
    I'm serving as the temporary ACPI maintainer. Please send all ACPI
    mails and patches you would normally send to Len to me, ideally cc
    linux-acpi@vger.kernel.org.

    As usual please put all ACPI bug reports into http://bugzilla.kernel.org.

    First (in case he still reads that) I would like to thank Len (and all
    the other ACPI hackers of course) for all the great work done on the ACPI
    code in the last years, turning it from a problem child to a quite
    respectable kernel subsystem.

    I'm not as deep in all things ACPI as Len is, so I'll often rely on
    the various other ACPI hackers for specific issues.

    My main goal will be to merge patches from the usual contributors and
    try to keep the ACPI bugs and regressions under control. I don't plan
    many new features, but features already in progress will be processed
    as they are ready.

    I'm also not full time working on ACPI, but also active in other areas.
    This means I will not write that many ACPI patches myself
    or do extensive testing on my own, but mostly focus on review and merging
    and bug triage.

    The git tree setup for the merges will be announced later. I won't
    directly use Len's tree.

    I'll take over all patches Len has already queued, so no need to
    resubmit them. But if he doesn't have something acknowledged already
    you want to be included, please retransmit it to me.

    The .27 merge will be primarily patches Len has already queued
    in his release tree.

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

  2. Re: Temporary ACPI maintainer for this summer

    On Mon, 30 Jun 2008, Andi Kleen wrote:
    > My main goal will be to merge patches from the usual contributors and
    > try to keep the ACPI bugs and regressions under control. I don't plan
    > many new features, but features already in progress will be processed
    > as they are ready.
    >
    > I'm also not full time working on ACPI, but also active in other areas.
    > This means I will not write that many ACPI patches myself
    > or do extensive testing on my own, but mostly focus on review and merging
    > and bug triage.
    >
    > The git tree setup for the merges will be announced later. I won't
    > directly use Len's tree.


    Andi,

    Len usually stores all changes from different sub-maintainers in separate
    topic branches, and as long as the tree had not been sent to Linus for
    mainline merge yet, he would even let us resubmit patchsets (instead of
    asking for incremental fixes): he'd just drop the old topic branch with
    that patchset, and create it anew using the new patchset.

    Not every sub-maintainer took advantage of this, but some of us did. It
    would be nice to know beforehand how you're going to handle these issues
    (i.e. do you prefer incremental fixing on stuff already staged for
    submission, or a cleaned-up resubmission for re-staging?)

    Also, as you should know, Len is the upstream path for some "platform
    drivers" that are big ACPI users but not ACPI drivers in itself (mostly
    laptop firmware drivers that live in drivers/misc).

    These drivers have ties to subsystems spread all over the kernel (major ACPI
    ties, but also leds, input, rfkill, gpio, hwmon...), so they often get
    patches that require late merging (end of the merge window, early -rc1)
    because of dependencies to subsystems outside ACPI. Len was fine with it,
    as long as the changes were local to the drivers (very low breakage risk for
    anything else in the kernel).

    > I'll take over all patches Len has already queued, so no need to
    > resubmit them. But if he doesn't have something acknowledged already
    > you want to be included, please retransmit it to me.


    You will get a bunch of thinkpad-acpi patches that depend upon net-next-2.6
    soon... I was waiting for some rfkill improvements to land on net-next-2.6
    before submitting code that needs them.

    That's something else I'd like to know. Do you prefer to get such changes
    [that depend on stuff still being submitted to other subsystems] early, or
    only after their dependencies are already on a (mostly) assured path to
    mainline?

    --
    "One disk to rule them all, One disk to find them. One disk to bring
    them all and in the darkness grind them. In the Land of Redmond
    where the shadows lie." -- The Silicon Valley Tarot
    Henrique Holschuh
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: Temporary ACPI maintainer for this summer


    > Len usually stores all changes from different sub-maintainers in separate
    > topic branches, and as long as the tree had not been sent to Linus for
    > mainline merge yet, he would even let us resubmit patchsets (instead of
    > asking for incremental fixes): he'd just drop the old topic branch with
    > that patchset, and create it anew using the new patchset.


    I don't plan to use topic branches, but have a quilt/guilt workflow
    that makes it possible to drop patches.

    > Not every sub-maintainer took advantage of this, but some of us did. It
    > would be nice to know beforehand how you're going to handle these issues
    > (i.e. do you prefer incremental fixing on stuff already staged for
    > submission, or a cleaned-up resubmission for re-staging?)


    I prefer cleaned-up resubmission in general over incremental changes.
    I would just merge the incrementals into the original patches anyways,
    so the submitter does that it is best.


    > These drivers have ties to subsystems spread all over the kernel (major ACPI
    > ties, but also leds, input, rfkill, gpio, hwmon...), so they often get
    > patches that require late merging (end of the merge window, early -rc1)
    > because of dependencies to subsystems outside ACPI. Len was fine with it,
    > as long as the changes were local to the drivers (very low breakage risk for
    > anything else in the kernel).


    Ok. We'll need to talk about that in detail.

    >> I'll take over all patches Len has already queued, so no need to
    >> resubmit them. But if he doesn't have something acknowledged already
    >> you want to be included, please retransmit it to me.

    >
    > You will get a bunch of thinkpad-acpi patches that depend upon net-next-2.6
    > soon... I was waiting for some rfkill improvements to land on net-next-2.6
    > before submitting code that needs them.
    >
    > That's something else I'd like to know. Do you prefer to get such changes
    > [that depend on stuff still being submitted to other subsystems] early, or
    > only after their dependencies are already on a (mostly) assured path to
    > mainline?


    Earlier. The tree would be based on linux-next.

    -Andi

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

+ Reply to Thread