On 2018-04-03 02:03 PM, Daniel Vetter wrote: > On Tue, Apr 3, 2018 at 1:52 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: >> On Tue, Apr 3, 2018 at 1:13 PM, Lucas Stach <dev@xxxxxxxxxx> 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@xxxxxxxx> 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). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
