[Mesa-dev] rules for merging patches to libdrm

[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 at gmail.com> wrote:
> On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie <airlied at gmail.com> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel