All of lore.kernel.org
 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

WARNING: multiple messages have this Message-ID (diff)
From: Lukas Wunner <lukas@wunner.de>
To: Matt Fleming <matt@codeblueprint.co.uk>
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 10:57:48 +0200	[thread overview]
Message-ID: <20160922085748.GA3546@wunner.de> (raw)
In-Reply-To: <20160922083402.GA16071@codeblueprint.co.uk>

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: 10+ 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 15:12     ` Grant Likely
2016-09-21 17:59   ` Lukas Wunner
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: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]
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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.