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
So the 'master' branch you've mentioned would sort of be the equivalent
to drm-intel-nightly. Yeah, that would definitely work.