On Tue, Jan 31, 2017 at 02:31:32PM -0500, Sean Paul wrote: > On Tue, Jan 31, 2017 at 07:01:44PM +0100, Daniel Vetter wrote: > > For the experiement we have right now Eric (with vc4) and Sean Paul > > (with rockchip and zte) volunteering, and Gerd (entire pile of qemu > > drivers) and Boris (atmel) are also considering to participate. I > > think that's enough to get started and figure things out as we go. > > > > I tried to summarize the main points from the rfc discussions into a > > short chapter. > > Did we decide on whether we're using a topic branch to start out? Also, are you > on the hook for pull requests? Hm, I guess that was too implicit. The idea is that anything small goes directly into drm-misc-next, and only really huge stuff (I've picked an arbitrary limit of 20+ patches) goes into a topic branch. That's definitely something we need to refine as we go I think. But for one-off patches I think the common tree is really a benefit, since no coordination between subsytem wide refactoring and driver patches is needed through pull requests. And yes since it's the same tree I'm volunteering for pull requests. dim status tells me when there's something pending (I wrote that a bit ago as prep to make drm-misc easy for me). -Daniel > > Sean > > > > > v2: Spelling fixes (Anholt). > > > > Cc: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxxxxxxx> > > Cc: Eric Anholt <eric@xxxxxxxxxx> > > Cc: Sean Paul <seanpaul@xxxxxxxxxxxx> > > Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx> > > Cc: Mark Yao <mark.yao@xxxxxxxxxxxxxx> > > Cc: Shawn Guo <shawnguo@xxxxxxxxxx> > > Acked-by: Sean Paul <seanpaul@xxxxxxxxxxxx> > > Acked-by: Gerd Hoffmann <kraxel@xxxxxxxxxx> > > Acked-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxxxxxxx> > > Acked-by: Eric Anholt <eric@xxxxxxxxxx> > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > > --- > > drm-misc.rst | 30 ++++++++++++++++++++++++++++++ > > 1 file changed, 30 insertions(+) > > > > diff --git a/drm-misc.rst b/drm-misc.rst > > index 3d711ec60047..7f7233cf3c61 100644 > > --- a/drm-misc.rst > > +++ b/drm-misc.rst > > @@ -93,6 +93,36 @@ Right now the only hard merge criteria are: > > * See also the extensive `committer guidelines for drm-intel > > <drm-intel.html#committer-guidelines>`_. > > > > +Small Drivers > > +============= > > + > > +Small drivers, where a full tree is overkill, can be maintained in drm-misc. For > > +now it's just an experiment with a few drivers to figure out a working process. > > +Slightly different rules apply: > > + > > +* Small is measured in patches merged per kernel release. The occasional big > > + patch series is still acceptable if it's not a common thing (e.g. new hw > > + enabling once a year), and if the series is really big (more than 20 patches) > > + it should probably be managed through a topic branch in drm-misc and with a > > + separate pull request to drm maintainer. dim_ supports this with the > > + create-branch command. > > + > > +* Group maintainership is assumed, i.e. all regular contributors (not just > > + the primary maintainer) will get commit rights. > > + > > +* Since even a broken driver is more useful than no driver minimal review > > + standards are a lot lower. The default should be some notes about what could > > + be improved in follow-up work and accepting patches by default. Maintainer > > + group for drivers can agree on stricter rules, especially when they have a > > + bigger user base that shouldn't suffer from regressions. > > + > > +* Minimal peer-review is also expected for drivers with just one contributor, > > + but obviously then only focuses on best practices for the interaction with drm > > + core and helpers. Plus a bit looking for common patterns in dealing with the > > + hardware, since display IP all has to handle the same issues in the end. In > > + most cases this will just along the lines of "Looks good, Ack". drm-misc > > + maintainers will help out with getting that review market going. > > + > > Tooling > > ======= > > > > -- > > 2.11.0 > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Sean Paul, Software Engineer, Google / Chromium OS -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
