EFI co-maintainer

EFI co-maintainer

[Matt Fleming]

Folks,

I've asked, and Ard has agreed to step up and help me co-maintain the
EFI subsystem.

Given that there are now two maintainers, we're moving to a shared git
repository on kernel.org, hosted at,

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git

Expect a MAINTAINERS patch soon.

I do plan on keeping the existing tree in sync for the time being, so
it won't actually matter which repository people base their patches
on. Hopefully the disruption to patch submitters will be minimal.

Thanks again Ard!

Re: EFI co-maintainer

[Grant Likely]

On Wed, Sep 21, 2016 at 4:09 PM, Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:
> Folks,
>
> I've asked, and Ard has agreed to step up and help me co-maintain the
> EFI subsystem.
>
> Given that there are now two maintainers, we're moving to a shared git
> repository on kernel.org, hosted at,
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
>
> Expect a MAINTAINERS patch soon.
>
> I do plan on keeping the existing tree in sync for the time being, so
> it won't actually matter which repository people base their patches
> on. Hopefully the disruption to patch submitters will be minimal.
>
> Thanks again Ard!

Brilliant! That is excellent news.

g.

Re: EFI co-maintainer

[Lukas Wunner]

Hi Matt, Hi Ard,

On Wed, Sep 21, 2016 at 04:09:12PM +0100, Matt Fleming wrote:
> I've asked, and Ard has agreed to step up and help me co-maintain the
> EFI subsystem.
> 
> Given that there are now two maintainers, we're moving to a shared git
> repository on kernel.org, hosted at,
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
> 
> Expect a MAINTAINERS patch soon.
> 
> I do plan on keeping the existing tree in sync for the time being, so
> it won't actually matter which repository people base their patches
> on. Hopefully the disruption to patch submitters will be minimal.
> 
> Thanks again Ard!

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.

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.

Thanks again,

Lukas

Re: EFI co-maintainer

[Matt Fleming]

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?

Re: EFI co-maintainer

[Ard Biesheuvel]

On 22 September 2016 at 09:34, Matt Fleming <matt@codeblueprint.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.

Re: EFI co-maintainer

[Lukas Wunner]

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