Linux EFI development
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
To: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Ard Biesheuvel
	<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Subject: Re: EFI co-maintainer
Date: Thu, 22 Sep 2016 10:57:48 +0200	[thread overview]
Message-ID: <20160922085748.GA3546@wunner.de> (raw)
In-Reply-To: <20160922083402.GA16071-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>

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

      parent reply	other threads:[~2016-09-22  8:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-21 15:09 EFI co-maintainer Matt Fleming
     [not found] ` <20160921150912.GM2892-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-09-21 15:12   ` Grant Likely
2016-09-21 17:59   ` Lukas Wunner
     [not found]     ` <20160921175951.GA3387-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2016-09-22  8:34       ` Matt Fleming
2016-09-22  8:49         ` Ard Biesheuvel
     [not found]         ` <20160922083402.GA16071-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-09-22  8:57           ` Lukas Wunner [this message]

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=20160922085748.GA3546@wunner.de \
    --to=lukas-jfq808j9c/izqb+pc5nmwq@public.gmane.org \
    --cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org \
    --cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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