RFC: drm-misc for small drivers?

[Sean Paul]

On Thu, Jan 26, 2017 at 05:42:12PM +0000, Liviu Dudau wrote:
> 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.

I'm not certain number of people is a good metric, TBH. There are cases
where a lot of people are working on a driver, but the patches are not being
merged to the maintainer tree. In these cases, it makes sense to migrate the
driver to -misc and have the community merge the patches.

I think most candidates should be fairly obvious without coming up with rigid
criteria.

Sean

<snip>

-- 
Sean Paul, Software Engineer, Google / Chromium OS