On Thu, Jul 5, 2018 at 3:53 PM, Jani Nikula <jani.nikula@xxxxxxxxx> wrote: > On Wed, 27 Jun 2018, Daniel Vetter <daniel@xxxxxxxx> wrote: >> On Wed, Jun 27, 2018 at 5:13 PM, Jani Nikula <jani.nikula@xxxxxxxxx> wrote: >>> As a rule of thumb, don't change patches while committing. >>> >>> Cc: Imre Deak <imre.deak@xxxxxxxxx> >>> Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx> >>> --- >>> 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@xxxxxxxxxxxxxxxxxxxxx >>> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
