On Wed, 24 Aug 2016, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
