Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

From: Jani Nikula <jani.nikula@linux.intel.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics <intel-gfx@lists.freedesktop.org>,
	DRI <dri-devel@lists.freedesktop.org>
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Date: Wed, 24 Aug 2016 16:33:59 +0300	[thread overview]
Message-ID: <8737lu70l4.fsf@intel.com> (raw)
In-Reply-To: <20160824114206.17c98d9d@canb.auug.org.au>

On Wed, 24 Aug 2016, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
>   drivers/gpu/drm/i915/intel_display.c
>
> between commits from the drm-intel-fixes tree (some of which are
> cherry-picked from the drm-intel tree) and teh same and other commits
> from the drm-inte tree.  These are just going to cause new conflicts
> every time you touch this file again in either tree (which happens a
> lot :-().
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider only putting
> the fix patches into the drm-intel-fixes tree and then getting them
> into the drm-intel tree by merging the -fixes tree instead of
> cherry-picking them the other way.

We used to do that, but switched to the current model instead. The main
reason was that we wanted our development branch to always get the fixes
first, without delay. We have several committers, and we want to make it
efficient and hassle free for them to get fixes applied.

The drm-intel tree is a fast moving target. If we fix something in
-fixes, there's no guarantee the fix applies to -next. It is more
important that we get the fix in -next, and all future kernels. If the
fix is important for current and stable kernels, we can do the
backport. This way, we can always resolve conflicts with the code in
-next, and be sure it contains all the fixes. If only -fixes had the
fixes, we'd have nightmare conflict resolutions trying to ensure none of
the fixes get dropped while merging.

Finally, you don't always know in advance whether the patch should be
applied to -next or -fixes. We'd end up with cherry-picks like this
anyway. Now we can do QA on the fixes in -next, and choose the ones to
backport.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel