[Intel-xe] [PATCH 0/7] drm/xe: Code cleanup

[Jani Nikula]

On Tue, 08 Aug 2023, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
> On Tue, Aug 08, 2023 at 06:05:40PM +0300, Jani Nikula wrote:
>>On Tue, 08 Aug 2023, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
>>> On Tue, Aug 08, 2023 at 01:47:50PM +0300, Jani Nikula wrote:
>>>>On Mon, 17 Jul 2023, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
>>>>> On Thu, Jul 13, 2023 at 04:33:52PM -0400, Rodrigo Vivi wrote:
>>>>>>On Thu, Jul 13, 2023 at 03:06:04PM +0000, Francois Dugast wrote:
>>>>>>> Fix minor typos and reduce ERRORs reported by checkpatch.pl from 95 to 22.
>>>>>>
>>>>>>I wonder if we should do this with !fixup patches...
>>>>>
>>>>> I think that would be a nightmare to thread through the conflicts.
>>>>
>>>>For display it's a nightmare we have to plunge through. And this just
>>>>made it worse.
>>>
>>> This is automatically resolved when we move display up in the branch
>>> though.  "Automatically" meaning that the pour sould doing the rebase
>>> has to resolve the conflicts. I don't like doing it, but what's the
>>> alternative? Last rebase I did a "squash-heavy approach" because moving
>>> display up means some commits don't make sense anymore, even if they
>>> apply correctly.  Those coding style changes would just be squashed in
>>> the respective commits.
>>
>>Squashing is easy if you have respective commits with 1:1 mapping, but
>>if you have one commit fixing multiple commits, it gets tricky.
>
> no, what I meant is that I turned 10 or so commits into 1 squash to the
> "Add display".  Simply because after moving them up in the branch they
> don't make much sense anymore and just make it difficult to land
> refactors like this on top. It's a nightmare to keep in the long run
> that I should rather avoid. IMO it was fine for a few weeks, but not for
> the several months we are in this situation.

The single huge "add display" is fine for xe, but that doesn't hold for
changes to i915.

All the other decisions regarding the branch management are subject to
that. The proposed changes to i915 must have a clean, sensible history,
and can't be part of patches the likes of "drm/i915/display: Remaining
changes to make xe compile" and "drm/xe/display: Implement display
support".

A month or so ago the latter didn't have a single change to i915. Now it
has several, and they mostly touch stuff changed by the former.

xe development needs to regard i915 as an upstream driver that you can't
change nilly willy outside of drm-intel-next.


BR,
Jani.



-- 
Jani Nikula, Intel Open Source Graphics Center