Apparently my git (v2.40.0) does more warnings and we're not silencing
all the possible ones in the commit_rerere_cache function

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Introduce stricter rules for topic/core-for-CI management. Way too many
commits have been added over the years, with insufficient rationale
recorded in the commit message, and insufficient follow-up with removing
the commits from the topic branch.

New rules:

1. Require maintainer ack for rebase. Have better gating on when rebases
   happen and on which baselines.

2. Require maintainer/committer ack for adding/removing commits. No
   single individual should decide.

3. Require gitlab issues for new commits added. Improve tracking for
   removing the commits.

Also use the stronger "must" for commit message requiring the
justification for the commit being in topic/core-for-CI.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: David Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: dim-tools@lists.freedesktop.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

In case a fix was not propagated yet to upstream, the
original commit sha won't be found hence the fix of this
fix will be missed during the cherry-pick.

Since dim cherry-picks reliably adds the -x "(cherry picked
from" message, let's also grep in the log to see if that
was the case, before we give up and forget.

Also, if that's the case, let's then fix the 'Fixes:' tag.

v2: Actually replaces the 'Fixes:' tag, otherwise dim doesn't
allow us to push giving the following message:
"Fixes: SHA1 in not pointing at an ancestor:"
"dim: ERROR: issues in commits detected, aborting"

v3: - Also consider fix of fixes in drm-intel-fixes besides
      the drm-intel-next-fixes.
    - Use intel_remote branches instead of local.
    - And run the check unconditionally as suggested by Daniel.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

After setting up drm-rerere, the integration config must be read again
to setup the environment variables with list of remotes/branches.
Otherwise the setup will be left incomplete, with drm-tip and drm-rerere
being the only branches configured.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>

Seems that we've had zero documentation on topic/core-for-CI. Describe
the branch and the current process.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

The .. contents:: directive adds an in-page table of contents for a nice
overview.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Maintainer tools is a project of its own. Reference the project page.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

In line with other repos.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Primarily fix the glaring omission of drm-intel-gt-next from the
documentation, but also clarify and clean up other details.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Can't think of why the complicated style for document titles was chosen
to begin with.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

sphinx-autobuild [1], when available, lets you run a local development
server that automatically rebuilds Sphinx documentation on changes in
the filesystem, with live-reload in the browser. This makes editing
documentation a slightly nicer experience.

Add livehtml target to run the server.

[1] https://pypi.org/project/sphinx-autobuild/



Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Commit ea3d1418 ("dim: Use git apply to apply patch") changed dim
behaviour in that it now accepts fixup patches that can create new
files, and those need to be applied using 'git apply' instead of plain
'patch'. Bump dim version to 2 to be able to require this feature.

We'll also need to bump the dim version requirement (DIM_MIN_VERSION) to
2 in nightly.conf to account for the fixups that need this change.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

This allows us to add new files in a fixup, required for unbreaking
drm-tip.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>

The dim tool supports a cherry-pick that is a glorified version of the git
command but adds additional metadata and checks if there are any follow-up
commits referencing the one being cherry-picked.

Let's document in the getting started page that the dim command should be
used instead of just git cherry-pick. That way people will be aware of it.

This is useful to avoid cherry-picking commits but miss existing fixes for
them, which would introduce unnecessary regressions in the target branch.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Even in feature freeze it can happen that the broken patch is only in
drm-misc-next, and then applying to drm-misc-next-fixes will
rightfully stumble over dim's Fixes: validation since the sha1 wont be
an ancestor.

Fix that by adding another check.

v2: Less confusing wording (Marek)

Reviewed-by: Marek Vasut <marex@denx.de>
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

We call assert_repo_clean() from a few places and for some of them, it's
not clear PWD would matter, example: dim ub

Clarify what's the working tree dim is complaining about.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

This is useful for generating drm-tip without pushing, so one can try a
build from drm-tip branch before pushing.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

If we already have a fixup file for a certain branch, we would override
any previous fixups. Just appending to the previous diff (even if
already containing the same path) seems to work better.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

If the email comes from a source that encodes the mbox body as base64
for whatever reason, the grep would fail. If it fails, fallback to using
git-mailinfo which will re-encode it.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

Javier Martinez Canillas authored 3 years ago and Simona Vetter committed 3 years ago

By default the git-format-patch command generates patches with prefixes
for the source and destination (-p1), and is also what git-am uses as a
default. The command strips the first leading path component when patch
is applied (unless a different -p<num> argument is used).

But the patch generating behaviour can be changed with git-format-patch
--no-prefix argument (or setting 'diff.noprefix = true' in .gitconfig).

Patches with no source and destination prefixes can confuse the git-am
3-way merge logic, since stripping the first path component will lead
to wrong paths for newly added files.

To avoid this, check that patches to apply are using git-format-patch's
defaults prefixes to make sure that git-am defaults are safe to use too.

Since there are developers that generate patches without using git, make
this an error but allow to still continue when using the dim -f option.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Way out of date.

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

They're very often just beaurocratic paperwork pushing because
maintainers refuse to give acks for merging patches through a single
tree. I guess the snarky intro wasn't clear enough, so elaborate.

Given that we don't even talk about topic branches anywhere else in
the docs hopefully this makes things a bit clearer.

v2: Fix typo (Maarten)

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

We should never run the pull with the rebase strategy. Ever.

That messes up with our commits. Specially with the top
one where dim expects a merge commit and it amends from and
link info.

So, let's forbid the rebase strategy overriding any user
config.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

        if [[ "x$1" = "xcd" ]]; then
              ^---^ SC2268: Avoid x-prefix in comparisons as it no longer serves a purpose.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

There's nothing we can do, but also I was baffled about what's going on.
The reason was that a topic branch was deleted on the server, but not
removed from nightly.conf. Which means git merge fails, but not in a way
we expect, so we keep falling over until this git commit (which should
always succeed) also falls over and the scrip just stops.

Make the failure a notch more verbose for next time around.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Another thing to do having obtained a drm-intel-gt-next co-maintainer hat.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This will allow integrating drm-intel-gt-next with linux-next

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

We have all these reminders to actually type a commit message, but
--no-commit doesn't imply --no-ff, so let's fix that.

Noticed because Maarten managed to do a fast-forward backmerge into
drm-misc-next somehow.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

It's not exactly trivial to add the smarts to properly check for pushing
backmerges, rebases, topic branches and subtree branches (such as
gvt). For a start, prompt the user with hints about what's going on.

Cc: Daniel Vetter <daniel@ffwll.ch>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

We kinda left this out, and I like the wording from the drm-intel
side, so add that. Motivated by a discussion with Christian.

Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Cc: Christian König <christian.koenig@amd.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Also try the mail address, just in case that matches and all the name
mangling tests we do don't help.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Ville Syrjälä authored 4 years ago and Jani Nikula committed 3 years ago

We actually want to use git filter-branch, so make it shut
up and do what it's told.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Ville Syrjälä authored 4 years ago and Jani Nikula committed 3 years ago

Trying to suck in a Fixes tag doesn't work currently due to the
double quotes contained within. Escape those so the shell stuff
doesn't get confused and we get the expected results.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Simon Ser authored 4 years ago and Simona Vetter committed 4 years ago

Python 2 has been end-of-life'd, and d79c5784 ("dim: fix handling of 8-bit
non-UTF-8 messages") relies on functions introduced in Python 3.2.

Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Simon Ser authored 4 years ago and Simona Vetter committed 4 years ago

Python's open() function will return a file object that decodes input
bytes to an UTF-8 string. Python assumes all files are UTF-8 by default
(unless an explicit encoding param is passed).

This works fine with 7-bit and UTF-8 messages. However, when a message
uses a 8-bit Content-Transfer-Encoding and a non-UTF-8 charset (such as
iso-8859-1), Python will error out.

To prevent this, open the file in binary mode to prevent Python from
doing any charset conversion under-the-hood.

Signed-off-by: Simon Ser <contact@emersion.fr>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Switching from using drm-intel-next-queued to drm-intel-next requires a
flag-day change. This is the dim change to switch to drm-intel-next. For
now, keep the sub-command names such as "conq" and "push-queued", and
change everything under the hood. Prevent pushes to
drm-intel-next-queued.

The flag-day change should be rolled with:

1) Bump minimum dim version with DIM_MIN_VERSION=1 in nightly.conf

2) Sync drm-intel-next-queued to drm-intel-next

3) Push this change to maintainer-tools

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Was disabled because of flaky infrastructure, Benjamin says it's
looking good now.

Cc: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

The character set decoding added in commit b66d07db ("dim: decode
email message content charset to unicode") started failing with unicode
decoding failures under certain conditions. (Specifically python 3 and
mboxes downloaded from patchwork.)

Instead of raising UnicodeDecodeErrors, replace values that can't be
converted with U+FFFD (REPLACEMENT CHARACTER, �).

Reported-by: Dave Airlie <airlied@gmail.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>