Re: RFC: drm-misc for small drivers?

[Liviu Dudau <liviu@dudau.co.uk>]

On Thu, Jan 26, 2017 at 02:12:16PM -0500, Sean Paul wrote:
> 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.

Sorry, I should've been more explicit: I was referring to the number of
contributors with public commit rights, not all the engineers involved. In
Mali DP's case we do most of the development in the open, so all the engineers
are free to merge the patches into the current public git tree after internal
review that tries to catch the evident issues.

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

Agree and I'm not asking for rigidity here, just clarifications (or guidance)
on when a team should consider appying for joining to / splitting from drm-misc.

Best regards,
Liviu

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