Re: [PATCH 00/17] drm: rename various struct members "dev" -> "drm"

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

 



Am 13.07.23 um 16:10 schrieb Uwe Kleine-König:
Hello Maxime,

On Thu, Jul 13, 2023 at 01:17:43PM +0200, Maxime Ripard wrote:
On Thu, Jul 13, 2023 at 12:39:40PM +0200, Uwe Kleine-König wrote:
On Thu, Jul 13, 2023 at 12:23:50PM +0300, Jani Nikula wrote:
On Thu, 13 Jul 2023, Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
after most feedback for my series "drm/crtc: Rename struct drm_crtc::dev
to drm_dev"[1] was positive in principle, here comes a new series.
I find it obnoxious to send a new series within 24 hours of the first,
while the discussion is still in progress, and it's a misrepresentation
of the in-progress dicussion to say most of the feedback was positive.

This is not the way to reach consensus.
Let me tell you I didn't had any obnoxious intentions when sending this
new series. I honestly still think that the feedback was mostly positive
to the idea to get rid of struct drm_device *dev. Most discussion was
about splitting the series and the right name to use instead of "dev".
And then you have a former and current maintainers that tell you that
they'd prefer not to merge it at all.
I went back to the previous thread rereading the replies I got yesterday
(i.e. the ones I was aware when I started to respin the series). By then
following people stated their opinion:

  - Paul Kocialkowski
    Is happy with the status quo
    naming: drm_dev > { drmdev, drm }
  - Thomas Zimmermann
    All data structures should be converted
    naming: drm > *
  - Javier Martinez Canillas
    Generally in favour (also via irc)
    Wants a single patch
    naming: drm > drm_dev > dev
  - Russell King
    Sent a "Reviewed-by, Thanks"
  - Christan König
    Wants a single patch
    naming: don't care

Well I don't care about the naming, but I care about avoiding additional unnecessary work.

So I'm not very keen about the naming change either because I think that this is just irrelevant.

Regards,
Christian.

  - Maxime Ripard
    Wants a single patch
  - Sui Jingfeng
    no union
    naming: { drm, ddev } > drm_dev > dev
  - Luben Tuikov
    Wants a single patch
    naming: drm_dev > { drm, dev }
  - Jani Nikula
    unnecessary change.(is this a "no" or a "don't care"?)
    naming: drm > *
  - Sean Paul
    doesn't like this change

I admit I'm not aware about the roles here, but up to then only Sean
Paul wrote a clear no and maybe Jani Nikula a small one. I interpreted
Paul Kocialkowski's replay as indifferent to the renaming. All others
were in favour or only criticised details and naming.

What did I miss (apart from today's replies which indeed are more
negative:

  - Thierry Reding
    Agreed to Jani Nikula that this change is
    unnecessary, also understood that for non-DRM people it might be
    confusing.
    naming: dev > drm > *
  - Thomas Zimmermann
    Agreed to Sean Paul about the too high downsides
  - Geert Uytterhoeven
    In favour (also before via irc)
)?

Ignoring those concerns
I'm really surprised by this suggestion. Either I really missed
something, or I'd like to ask these maintainers to communicate in a more
obvious way. If I send a series and I get feedback like "If you rename
drm_crtc.dev, you should also address *all* other data structures." (by
Thomas Zimmermann) or "When you automatically generate the patch (with
cocci for example) I usually prefer a single patch instead." (by
Christan König) then I would expect that if they oppose the underlying
idea of the series they would say so, too. I'm sorry, I cannot read a
concern (to the underlying idea) from these replies. And so I addressed
the feedback about the details with a new series to have an updated base
for the discussion.

and then sending a new version right away is, if not obnoxious,
definitely aggressive.
If this is how you experience my submission even after I tried to
explain my real intentions, I'm sorry. And I'm sure there is a deep
misunderstanding somewhere.

Best regards
Uwe





[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