[git pull] drm for v4.17-rc1

[Daniel Vetter]

On Wed, Apr 04, 2018 at 12:36:20PM +0200, Michel Dänzer wrote:
> On 2018-04-03 02:03 PM, Daniel Vetter wrote:
> > On Tue, Apr 3, 2018 at 1:52 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> >> On Tue, Apr 3, 2018 at 1:13 PM, Lucas Stach <dev at lynxeye.de> wrote:
> >>> Hi Daniel,
> >>>
> >>> Am Dienstag, den 03.04.2018, 12:01 +0200 schrieb Daniel Vetter:
> >>>> On Tue, Apr 3, 2018 at 11:58 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> >>>>> On Thu, Mar 29, 2018 at 11:15:50AM +1000, Dave Airlie wrote:
> >>>>>> Hi Linus,
> >>>>>>
> >>>>>> This is the main drm pull request for 4.17-rc1.
> >>>>>>
> >>>>>> I'm sending it early because Easter is coming and I'm going to be on
> >>>>>> holidays/have relatives staying for most of the next three weeks.
> >>>>>> I'll be near email for any emergency but otherwise not too engaged.
> >>>>>> I'll likely have two days back before the end of the merge window
> >>>>>> to vaccum up any fixes. Cannonlake and Vega12 support are probably the
> >>>>>> two major things. This pull lacks nouveau, Ben had some unforseen
> >>>>>> leave and a few other blockers so we'll see how things look or maybe
> >>>>>> leave it for this merge window.
> >>>>>>
> >>>>>> I'm off to eat my weight in chocolate.
> >>>>>
> >>>>> Droppping down to dri-devel.
> >>>>>
> >>>>> I've had some great fun with scripting maintainer statistics recently. One
> >>>>> thing I've done is looking at patches committed by the author themselves
> >>>>> (= stuff pushed by maintainers/committers), and how much formal
> >>>>> reviews/acks there are.
> >>>>>
> >>>>> Overall we're doing a fairly decent job, with 80+% of these patches
> >>>>> reviewed. Big drivers (i915 and amdgpu) do a pretty much perfect job, as
> >>>>> does everyone who's part of the drm-misc group. But the in-between drivers
> >>>>> less so. And given that everyone else has to go through mandatory reviews
> >>>>> (less than 50% of all patches are merged by maintainers/committers, even
> >>>>> in drm) I don't see why maintainers should be special and can skip review.
> >>>>>
> >>>>> Also, most of the drivers where review doesn't consistently happen are
> >>>>> developed by groups, so not hard to find a suitable review. Anyway, below
> >>>>> the stats of unreviewed maintainer patches for this pull here.
> >>>>>
> >>>>> I think some drivers we could perhaps stuff into drm-misc, others should
> >>>>> probably move to grou maintainership of some form.
> >>>>
> >>>> Aside, here's the list of top non-maintainer commits. Short summary is
> >>>> that AMD really should switch to a group maintainer model, but e.g.
> >>>> Laurent should probably become co-maintainer in some areas too ...
> >>>
> >>> To be honest I don't understand why you are trying to enforce your
> >>> model on everyone. Maybe the drm-misc thing has solved some problems
> >>> for you, but I just don't see the point why others who seem to have
> >>> something that works for them should switch to something different.
> >>>
> >>> Especially the AMD driver seems to work quite well the way it is
> >>> handled by those guys.
> > 
> > Not sure why you bring up AMD in support of doing things differently,
> > because AMD folks is one of those trees that consistently get
> > everything reviewed, and they're also thinking about switching to a
> > group maintainership model. Simply didn't get around to implement it
> > yet.
> 
> What exactly do you mean by "group maintainership model"? FWIW, AMD
> developers are already pushing their own reviewed changes to the
> internal amd-staging-drm-next branch, it's just usually Alex which sends
> them to Dave (but Christian has done that before when Alex was away).

Yeah I know, but Alex reapplies them all again, so it doesn't show up as
that. Or maybe he just rebases, and that's why they show up as all
committed by Alex. It is still slightly different from drm-misc/intel,
where committers push to permanent history directly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch