linux-kernel - Re: EFI co-maintainer

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, 22 Sep 2016 09:49:00 +0100
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Matt Fleming <matt@...eblueprint.co.uk>
Cc:     Lukas Wunner <lukas@...ner.de>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: EFI co-maintainer

On 22 September 2016 at 09:34, Matt Fleming <matt@...eblueprint.co.uk> wrote:
> On Wed, 21 Sep, at 07:59:51PM, Lukas Wunner wrote:
>>
>> That is great to hear, thanks a lot from me as well.
>>
>> Just curious, are there any plans to integrate the new repo into
>> linux-next?  It would be great to have testing as early as possible.
>
> Yes, the existing one is also part of linux-next once it gets merged
> into tip. The issue has been that I didn't send pull requests to tip
> frequently enough for that to happen on a regular basis.
>
> Ard has already mentioned that he'd like to see that change.
>

Well, given the recent developments, where architecture support for
arm64 and ARM is essentially in maintenance mode, and new development
is mainly focused on generic EFI features living under
drivers/firmware/efi, it might make sense to stop feeding through tip,
but go directly to Linus (and to -next)

Going straight to -next, but going through tip for actual merging
introduces a disparity that is outside of our control, i.e., patches
sometimes get 'fixed' en route (although, to be fair, this is usually
only commit log or other textual fixes in comments etc), but since it
is our responsibility as EFI maintainers to ensure that what is in
-next is what gets sent to Linus in the merge request, I think we
shouldn't have one without the other.

>> Also, if this isn't too much trouble, would it be possible to merge
>> urgent into next when patches are added in the future?  When I tested
>> my patches during this release cycle, I tried to pull in everything
>> from efi/urgent + efi/next into my development branch but hit some
>> non-trivial merge conflicts in portions of the EFI code I wasn't
>> familiar with.  And ISTR that efi/next was based on 4.7, not 4.8-rc.
>> In the end I just rebased my patches on efi/next, but felt a bit uneasy
>> as I wasn't testing what the code would eventually look like.
>
> This is a fair request. The only reason this hasn't happened in the
> past is that no one has ever asked for it to happen regularly.
>
> 'next' and 'urgent' are intended to be topic branches, and they're
> based on tags that align with their purpose - 'next' is new features
> and needs a stable base and lots of testing time, whereas 'urgent' is
> critical bug fixes and so needs to be based on the latest -rc.
>
> While I don't think it makes sense to merge those branches together,
> using the 'master' branch as the place with all the changes plus the
> merge resolutions sounds fine to me. This is similar to how the tip
> repository is structured.
>
> Would that work?

Works for me.