Hi all, We've discussed this a bit at LCA (with Dave and Eric), and it's probably best if I just summarize all the questions and opens and throw them out here for discussions: - When's a driver small enough for a shared tree, and when is a separate tree a good idea? i915 and amdgpu are definitely big, and there's definitely drivers who are really small and in-between it's unclear. Personally I think this is easy to do with a sliding scale, with using topic branches (we can do them in drm-misc easily) for bigger stuff, and if that's a common thing, split out the driver (thanks to the drm-tip integration tree there's not much of a difference in handling conflicts due to that anyway). - Should it be an entire separate tree for soc drivers? Problem here is that we lack a volunteer group (and imo it really should be a group to avoid the single-maintainer troubles) to run that. I think it's easier to proof the process first, and if we want a separate tree, split that out later on. This is the same thing we've done with drm-misc, first with a topic branch in drm-intel.git, then separate. I think it worked really well. - Should we require review or at least acks for patches committed by the author? We have a bunch of drivers with effectively just 1 person working on it, where getting real review is hard. But otoh a few of those 1-person drivers will become popular, and then it's good to start with establishing peer-review early on. I also think that requiring peer-review is good to share best practices and knowledge between different people in our community, not just to make sure the code is correct. For all these reasons I'm leaning towards not making an exception for drivers, and requiring the same amount of review for them if they go in through drm-misc as for any other patch. - Who's elligible? I think we could start small with a few volunteers and their drivers, and then anyone who's willing. - Should we force new submissions to be managed in that shared treee? I think for initial submission a separate pull request for approval-by-Dave is good (but we could do that with topic branches too). And it's also way too early to tell, probably better to first figure out how well this goes. - CI, needed? It would be great, but we're not there yet :( Atm drm-misc just has a bunch of defconfigs that need to always compile, and that's it. Long term I definitely want more, but we're just not there yet. And it's a problem in general for drm-misc. - dim scripts. Since we don't have a github flow where we can reasonably automate stuff on the server side we need something to automate on the client side. Thus far almost everyone seemed ok with the scripting that's used to drive drm-misc/intel/tip, but we can always improve things. And long term we can rework the approach however we want to really. - Other stuff I've missed? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
