Am 10.05.2016 um 07:05 schrieb Dave Airlie:
On 9 May 2016 at 18:17, Daniel Vetter <daniel@xxxxxxxx> wrote:
On Wed, May 04, 2016 at 02:26:42PM -0400, Alex Deucher wrote:
From: Chunming Zhou <David1.Zhou@xxxxxxx>
The release of the vmid owner was not handled
correctly. We need to take the lock and walk
the lru list.
Signed-off-by: Chunming Zhou <David1.Zhou@xxxxxxx>
Reviewed-by: Alex Deucher <alexander.deucher@xxxxxxx>
Reviewed-by: Monk Liu <monk.liu@xxxxxxx>
Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>
I know that it's super hard to get former proprietary driver teams to
stick their heads out on a public mailing lists. But imo being steward for
them is totally the worst case option you can pick long term. It means you
keep all the frustration of them not being fully in control (because
sometimes other people from outside the company jump in), never learning
how to driver the process themselves. And from the community pov it just
looks like code-drop over the wall. In my experience (I've been trying to
pull this off in public for almost 4 years now) trying to make exceptions
to get folks started just doesn't help anyone.
Imo contributors need to fence for their patches themselves (with you
helping behind the scenes ofc) from the start.
I'd prefer this as well, I'd also prefer at least people who do develop upstream
like Christian be set free to do so again, having patches spring on
the lists fully
formed isn't really great.
Yeah, completely agree.
I actually tried to work on the public list again. Especially since I'm
working on TTM improvements that would make things much easier.
The problem is that then internal people started to complain that some
patches only got reviewed and merged upstream, but not internally.
It would be also nice if there was more external discussion around
design decisions etc,
get the internal patch debate onto the mailing list.
Yeah, again completely agree. Alex and I already spend a lot of effort
trying to explain the difference between releasing code to the public
and making code open source.
Because at this rate I've no idea about most of the design internals
of the VM stuff,
and I really think you guys can do a lot better.
Maybe start setup another mailing list like intel-gfx for this, so
it's a bit more private
than dri-devel, but what is happening at the moment is worse than what
used to happen.
Yeah, that sounds like a good idea to me.
Regards,
Christian.
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
