Re: RFC: drm-misc for small drivers?

[Sean Paul <seanpaul@chromium.org>]

On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter 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. 

Big +1. In addition to spreading out the workload, driver maintainers should
still exercise ownership/stewardship.

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

Sounds reasonable.

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

At the risk of being on the hook for more driver reviews, I think we should
strive to review and fallback if it can't be sustained.

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

I think we could safely volunteer some drivers we haven't seen pull requests
from in a while.

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

No issues with dim on my side, seems like a natural choice.

> 
> - 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel