Re: [git pull] drm for v4.17-rc1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux