RFC: drm-misc for small drivers?

[Liviu Dudau]

On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote:
> Hi all,

Hi Daniel,

> 
> 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).

IMO the criteria should be based on the number of people involved in
each driver that have commit rights. The size of the driver should not
matter. There can be only one person working on a large and established
code base and be easy to handle with a topic branch in drm-misc, while
having a small (because it is new) driver that 3-5 people can all commit
into leads to a different dynamic. I'm interested on what are your (and
others) thoughts on the process for this.

> 
> - 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.

Hmm, are we mixing here GPU drivers with display ones, like we do on
the #dri-devel IRC channel? Because different people are going to have
different interests (obviously).

> 
> - 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.

I think it depends on the responsiveness of that driver maintainer. IF
we are happy with people making mistakes and fixing them quickly, then
we can be more lax on the review. I would personally like (or expect)
that at least the people sending pull request for drm-misc that includes
that driver do a quick review of the code because they know it is only
one person working on it.

> 
> - Who's elligible? I think we could start small with a few volunteers
> and their drivers, and then anyone who's willing.

I am not volunteering not excusing me from this, I would like more details
on the process before making a decision.

> 
> - 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.

+1

> 
> - 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.

Can you be more specific on who "everyone" is? I haven't used any of the
scripts from drm-misc/intel/tip.

> 
> - Other stuff I've missed?

Suggestions on how we address the ordering of pulls? If we depend in a
drivers in drm-misc on a change making it into Dave's tree, how will that
work?

Best regards,
Liviu

> 
> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel