On Mon, Dec 12, 2016 at 12:57:40PM +1000, Dave Airlie wrote: > 4) Why can't we put this in staging? > People have also mentioned staging, Daniel has called it a dead end, > I'd have considered staging for this code base, and I still might. > However staging has rules, and the main one is code in staging needs a > TODO list, and agreed criteria for exiting staging, I don't think we'd > be able to get an agreement on what the TODO list should contain and > how we'd ever get all things on it done. If this code ended up in > staging, it would most likely require someone dedicated to recreating > it in the mainline driver in an incremental fashion, and I don't see > that resource being available. So it's not just that I think the staging experience for drivers isn't good (e.g. imx, gma500), there's also the trouble that it's a separate tree and the coordination becomes a pain. That was very ugly around all the sync_file stuff imo, and for next time around we ever do that we should just put it into drm first and clean up second. We could do staging like with nouveau, but that's imo not really any different from just merging if we only slap a Kconfig depends upon the entire pile. So just don't see the benefit. I think stagin is good for checkpatch cleanup, but we already agreed that we're ok with ugly code if it's the stuff debugged by hw engineers. And for anything else like real refactoring I of big pieces of code I just don't see how staging makes sense. Maybe if it's a completely new subsystem, but the point here is that we want DC to integrate tighter with drm and be able to share code. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
