RFC: drm-misc for small drivers?

[Daniel Vetter]

On Mon, Jan 30, 2017 at 11:15:34AM +0100, Boris Brezillon wrote:
> Hi Daniel,
> 
> On Thu, 26 Jan 2017 18:08:42 +0100
> Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> 
> > 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.
> 
> I'd be happy to have the atmel-hlcdc driver maintained in this drm-misc
> tree. I just had to send a PR containing a single patch for 4.11, and it
> really feels like these simple fixes/improvements patches do not deserve
> a dedicated PR (not to mention that sometime I forget to send the
> PR and miss a release :-)).
> 
> Now, regarding the peer-review thing, I'm not against reviewing a few
> simple patches from time to time, but I don't think I'll have time to
> review entire new drivers, and I guess that's the kind of thing your
> looking for :-/.

It' should be equal for equal really imo, so if you have a few small
patches, then you'd need to review a few small patches to not drain the
review pool. I haven't figured out a good way to offload the
new-driver-review yet :-/

Anyway it sounds like we have enough interested folks for an attempt, I'll
try and type up some rough guidelines for the drm-misc docs and then we'll
see what happens.
-Daniel

> 
> > 
> > - 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
http://blog.ffwll.ch