RFC: drm-misc for small drivers?

[Daniel Vetter]

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