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] [day] [month] [year] [list]

Message-ID: <20160922085748.GA3546@wunner.de>
Date:   Thu, 22 Sep 2016 10:57:48 +0200
From:   Lukas Wunner <lukas@...ner.de>
To:     Matt Fleming <matt@...eblueprint.co.uk>
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 Thu, Sep 22, 2016 at 09:34:02AM +0100, Matt Fleming wrote:
> On Wed, 21 Sep, at 07:59:51PM, Lukas Wunner wrote:
> > 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.

Excellent, thank you.

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

Yes, sure thing.  And if efi/master is part of linux-next, you'll
automatically get testing for 'urgent' patches as well and thus a
bit of extra confidence before the merge into tip a few days later.

Just to provide an additional data point, the i915 folks have a
drm-intel-next branch and a drm-intel-fixes branch, the latter mostly
just cherry-picks from the former.  Plus there's drm-intel-nightly
which merges everything together (drm-intel + drm-misc branches,
Dave Airlie's drm-next, sound etc) and which my own development
branch is also based on.  Some people run drm-intel-nightly all
the time, plus the linux-next coverage this adds up to a considerable
safety net.

So the 'master' branch you've mentioned would sort of be the equivalent
to drm-intel-nightly. Yeah, that would definitely work.

Best regards,

Lukas