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