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

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.

> 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?