[DIM DOCS PATCH 2/2] doc: clarify what type of changes are acceptable at commit time

[Daniel Vetter]

On Thu, Jul 5, 2018 at 3:53 PM, Jani Nikula <jani.nikula at intel.com> wrote:
> On Wed, 27 Jun 2018, Daniel Vetter <daniel at ffwll.ch> wrote:
>> On Wed, Jun 27, 2018 at 5:13 PM, Jani Nikula <jani.nikula at intel.com> wrote:
>>> As a rule of thumb, don't change patches while committing.
>>>
>>> Cc: Imre Deak <imre.deak at intel.com>
>>> Signed-off-by: Jani Nikula <jani.nikula at intel.com>
>>> ---
>>>  drm-intel.rst | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drm-intel.rst b/drm-intel.rst
>>> index baf48f459dd9..ad8ff9739336 100644
>>> --- a/drm-intel.rst
>>> +++ b/drm-intel.rst
>>> @@ -196,6 +196,13 @@ An inexhaustive list of details to check:
>>>    coordinate with maintainers to avoid unnecessary pain with conflicts. Usually
>>>    some explicit merges are needed to avoid git getting lost.
>>>
>>> +* As a general rule, do not modify the patches while applying, apart from the
>>> +  commit message. If the patch conflicts, or needs to be changed due to review,
>>> +  have the author rebase, update and resend. Any change at this stage is a
>>> +  potential issue bypassing CI.
>>>
>> Should we also mention that merge conflicts need to be told to
>> maintainers, so that they can do a backmerge? Just because this blew
>> up recently for drm-misc ...
>
> Added bullet
>
> * Please notify maintainers (IRC is fine) of new merge conflicts during drm-tip
>   rebuild, so that they can do backmerges as needed.
>
> and pushed to get this done. Please amend if that's not what you wanted.

Personally I preferred committers told me before they wrestled a patch
into submission because it missed a required patch, then wrestled
drm-tip into submission with a nasty conflict on top. Doing a
backmerge first, pushing 2nd is much simpler, and fits into the bullet
about not modifying patches.

I'd have added something like "Also don't modify patches due to
conflicts. Instead ask maintainers to backmerge your required baseline
patches first, since that avoids tons of headaches later on with
conflicts in integration trees and pull requests." Or something like
that.
-Daniel

>
> Thanks,
> Jani.
>
>
>> -Daniel
>>
>>> +  At most, minor comment and whitespace tweaks are acceptable.
>>> +
>>>  On Confidence, Complexity, and Transparency
>>>  -------------------------------------------
>>>
>>> --
>>> 2.11.0
>>>
>>> _______________________________________________
>>> dim-tools mailing list
>>> dim-tools at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dim-tools
>
> --
> Jani Nikula, Intel Open Source Graphics Center



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch