From: Matt Fleming <matt@codeblueprint.co.uk>
To: Lukas Wunner <lukas@wunner.de>
Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
x86@kernel.org
Subject: Re: EFI co-maintainer
Date: Thu, 22 Sep 2016 09:34:02 +0100 [thread overview]
Message-ID: <20160922083402.GA16071@codeblueprint.co.uk> (raw)
In-Reply-To: <20160921175951.GA3387@wunner.de>
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?
next prev parent reply other threads:[~2016-09-22 8:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-21 15:09 EFI co-maintainer Matt Fleming
2016-09-21 15:12 ` Grant Likely
2016-09-21 17:59 ` Lukas Wunner
2016-09-22 8:34 ` Matt Fleming [this message]
2016-09-22 8:49 ` Ard Biesheuvel
2016-09-22 8:57 ` Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160922083402.GA16071@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=ard.biesheuvel@linaro.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).