From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jani Nikula 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 Message-ID: <8737lu70l4.fsf@intel.com> References: <20160824114206.17c98d9d@canb.auug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20160824114206.17c98d9d@canb.auug.org.au> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Stephen Rothwell , Daniel Vetter , Intel Graphics , DRI Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org List-Id: linux-next.vger.kernel.org T24gV2VkLCAyNCBBdWcgMjAxNiwgU3RlcGhlbiBSb3Rod2VsbCA8c2ZyQGNhbmIuYXV1Zy5vcmcu YXU+IHdyb3RlOgo+IEhpIGFsbCwKPgo+IFRvZGF5J3MgbGludXgtbmV4dCBtZXJnZSBvZiB0aGUg ZHJtLWludGVsIHRyZWUgZ290IGEgY29uZmxpY3QgaW46Cj4KPiAgIGRyaXZlcnMvZ3B1L2RybS9p OTE1L2ludGVsX2Rpc3BsYXkuYwo+Cj4gYmV0d2VlbiBjb21taXRzIGZyb20gdGhlIGRybS1pbnRl bC1maXhlcyB0cmVlIChzb21lIG9mIHdoaWNoIGFyZQo+IGNoZXJyeS1waWNrZWQgZnJvbSB0aGUg ZHJtLWludGVsIHRyZWUpIGFuZCB0ZWggc2FtZSBhbmQgb3RoZXIgY29tbWl0cwo+IGZyb20gdGhl IGRybS1pbnRlIHRyZWUuICBUaGVzZSBhcmUganVzdCBnb2luZyB0byBjYXVzZSBuZXcgY29uZmxp Y3RzCj4gZXZlcnkgdGltZSB5b3UgdG91Y2ggdGhpcyBmaWxlIGFnYWluIGluIGVpdGhlciB0cmVl ICh3aGljaCBoYXBwZW5zIGEKPiBsb3QgOi0oKS4KPgo+IEkgZml4ZWQgaXQgdXAgKHNlZSBiZWxv dykgYW5kIGNhbiBjYXJyeSB0aGUgZml4IGFzIG5lY2Vzc2FyeS4gVGhpcwo+IGlzIG5vdyBmaXhl ZCBhcyBmYXIgYXMgbGludXgtbmV4dCBpcyBjb25jZXJuZWQsIGJ1dCBhbnkgbm9uIHRyaXZpYWwK PiBjb25mbGljdHMgc2hvdWxkIGJlIG1lbnRpb25lZCB0byB5b3VyIHVwc3RyZWFtIG1haW50YWlu ZXIgd2hlbiB5b3VyIHRyZWUKPiBpcyBzdWJtaXR0ZWQgZm9yIG1lcmdpbmcuICBZb3UgbWF5IGFs c28gd2FudCB0byBjb25zaWRlciBvbmx5IHB1dHRpbmcKPiB0aGUgZml4IHBhdGNoZXMgaW50byB0 aGUgZHJtLWludGVsLWZpeGVzIHRyZWUgYW5kIHRoZW4gZ2V0dGluZyB0aGVtCj4gaW50byB0aGUg ZHJtLWludGVsIHRyZWUgYnkgbWVyZ2luZyB0aGUgLWZpeGVzIHRyZWUgaW5zdGVhZCBvZgo+IGNo ZXJyeS1waWNraW5nIHRoZW0gdGhlIG90aGVyIHdheS4KCldlIHVzZWQgdG8gZG8gdGhhdCwgYnV0 IHN3aXRjaGVkIHRvIHRoZSBjdXJyZW50IG1vZGVsIGluc3RlYWQuIFRoZSBtYWluCnJlYXNvbiB3 YXMgdGhhdCB3ZSB3YW50ZWQgb3VyIGRldmVsb3BtZW50IGJyYW5jaCB0byBhbHdheXMgZ2V0IHRo ZSBmaXhlcwpmaXJzdCwgd2l0aG91dCBkZWxheS4gV2UgaGF2ZSBzZXZlcmFsIGNvbW1pdHRlcnMs IGFuZCB3ZSB3YW50IHRvIG1ha2UgaXQKZWZmaWNpZW50IGFuZCBoYXNzbGUgZnJlZSBmb3IgdGhl bSB0byBnZXQgZml4ZXMgYXBwbGllZC4KClRoZSBkcm0taW50ZWwgdHJlZSBpcyBhIGZhc3QgbW92 aW5nIHRhcmdldC4gSWYgd2UgZml4IHNvbWV0aGluZyBpbgotZml4ZXMsIHRoZXJlJ3Mgbm8gZ3Vh cmFudGVlIHRoZSBmaXggYXBwbGllcyB0byAtbmV4dC4gSXQgaXMgbW9yZQppbXBvcnRhbnQgdGhh dCB3ZSBnZXQgdGhlIGZpeCBpbiAtbmV4dCwgYW5kIGFsbCBmdXR1cmUga2VybmVscy4gSWYgdGhl CmZpeCBpcyBpbXBvcnRhbnQgZm9yIGN1cnJlbnQgYW5kIHN0YWJsZSBrZXJuZWxzLCB3ZSBjYW4g ZG8gdGhlCmJhY2twb3J0LiBUaGlzIHdheSwgd2UgY2FuIGFsd2F5cyByZXNvbHZlIGNvbmZsaWN0 cyB3aXRoIHRoZSBjb2RlIGluCi1uZXh0LCBhbmQgYmUgc3VyZSBpdCBjb250YWlucyBhbGwgdGhl IGZpeGVzLiBJZiBvbmx5IC1maXhlcyBoYWQgdGhlCmZpeGVzLCB3ZSdkIGhhdmUgbmlnaHRtYXJl IGNvbmZsaWN0IHJlc29sdXRpb25zIHRyeWluZyB0byBlbnN1cmUgbm9uZSBvZgp0aGUgZml4ZXMg Z2V0IGRyb3BwZWQgd2hpbGUgbWVyZ2luZy4KCkZpbmFsbHksIHlvdSBkb24ndCBhbHdheXMga25v dyBpbiBhZHZhbmNlIHdoZXRoZXIgdGhlIHBhdGNoIHNob3VsZCBiZQphcHBsaWVkIHRvIC1uZXh0 IG9yIC1maXhlcy4gV2UnZCBlbmQgdXAgd2l0aCBjaGVycnktcGlja3MgbGlrZSB0aGlzCmFueXdh eS4gTm93IHdlIGNhbiBkbyBRQSBvbiB0aGUgZml4ZXMgaW4gLW5leHQsIGFuZCBjaG9vc2UgdGhl IG9uZXMgdG8KYmFja3BvcnQuCgpCUiwKSmFuaS4KCgotLSAKSmFuaSBOaWt1bGEsIEludGVsIE9w ZW4gU291cmNlIFRlY2hub2xvZ3kgQ2VudGVyCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3Rz LmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756084AbcHXNfU (ORCPT ); Wed, 24 Aug 2016 09:35:20 -0400 Received: from mga07.intel.com ([134.134.136.100]:43475 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754498AbcHXNew (ORCPT ); Wed, 24 Aug 2016 09:34:52 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,570,1464678000"; d="scan'208";a="752927893" From: Jani Nikula To: Stephen Rothwell , Daniel Vetter , Intel Graphics , DRI 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 In-Reply-To: <20160824114206.17c98d9d@canb.auug.org.au> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20160824114206.17c98d9d@canb.auug.org.au> User-Agent: Notmuch/0.22.1+62~g2a7b11b (https://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 24 Aug 2016 16:33:59 +0300 Message-ID: <8737lu70l4.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 Aug 2016, Stephen Rothwell 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