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šák:
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 <mattst88@xxxxxxxxx> wrote:
On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie <airlied@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
mesa-dev mailing list
mesa-dev@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
