From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?Christian_K=F6nig?= Subject: Re: [Mesa-dev] rules for merging patches to libdrm Date: Tue, 19 Nov 2013 16:04:33 +0100 Message-ID: <528B7E01.4080101@vodafone.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: =?windows-1252?Q?Marek_Ol=9A=E1k?= , Matt Turner Cc: "mesa-dev@lists.freedesktop.org" , dri-devel List-Id: dri-devel@lists.freedesktop.org For merging the patches for new hardware and/or features I agree on the = process of merging things bottom up. (e.g kernel first, then libdrm, = mesa last). But to give reasons for the merge into Linus tree it's = usually better to have a "big picture" you can validate the code against. So I think the very first step should be to publish everything on the = appropriate lists, and not try an approach like releasing the kernel = code first and waiting for it to show up upstream and then try to = release the userspace code build on top of it. I had this situation a couple of times where "management" people wanted = to release things bit by bit to "speed things up" and it always took me = a bit of time to explain that this wouldn't work in the open source = world (at least not with the Linux kernel). Christian. Am 19.11.2013 15:26, schrieb Marek Ol=9A=E1k: > Having patches on a mailing list is good enough, but generally if > people *trust* you that you will have an open userspace, that's good > enough too if you have people's trust. > > In my opinion, the required kernel code must land in Linus's tree > first. If it's not there, it's like it didn't exist at all. Then you > can merge and release dependent libdrm code. And after that, you can > merge dependent Mesa code. > > This is really common sense and I don't think we need a strict process > to enforce the rules. > > Marek > > On Fri, Nov 8, 2013 at 11:32 PM, Matt Turner wrote: >> On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie wrote: >>> Since we seemed to have some confusion over this I'll state it clearly = here. >>> >>> You should not merge kernel interface and ioctls to libdrm until they >>> have appeared in a git commit upstream with a stable id, this >>> generally means drm-next, but can also mean drm-intel-next. >> How does this interact with the rule that kernel interfaces require an >> open source userspace? Is "here are the mesa/libdrm patches that use >> it" sufficient to get the kernel interface merged? >> >> libdrm is easy to change and its releases are cheap. What problem does >> committing code that uses an in-progress kernel interface to libdrm >> cause? I guess I'm not understanding something. >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev