atseanpaul / review-o-matic Goto Github PK

For the purpose of SoB checks, strip @google.com and @chromium.org domains from the uploader's email for maximum forgiveness. This avoids failing SoB when a user's name doesn't match their SoB and they are using @google.com for uploading and @chromium.org for SoB.

Ex: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1601080

We hide them right now, but people are asking for them... so give the people what they want.

Folks should be able to specify a tag or a branch for cherry-picks

See https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1810475/2

Fail the review if a patch is posted and sourced from linux-next or drm-tip

See https://crrev.com/c/3489178/5

Ideally the script could tell the uploader when an unknown prefix is used. At the very least, the script should withhold its +1 in this case.

If a patch is FROMGIT and differs, ask the user to add a BACKPORT prefix to denote that it has changed from the upstream source.

If I patch prefix is just "BACKPORT" or "UPSTREAM", we should verify that the patch has landed in Linus' tree. If not, print an error suggesting the author use FROMLIST/FROMGIT.

https://thats.poorly.run now points to a YouTube video that has been removed for violating the terms of service.

WTF: https://chromium-review.googlesource.com/c/chromiumos/third_party/bluez/+/2137799/1#message-5957679c1ae01d497f0a8034f012eb6c46ac5a46

Some important mailing lists don't have patchwork instances, because patchwork doesn't scale well for them. Notably, LKML doesn't have one. Instead, people use lore.kernel.org.

It'd be nice if we could get FROMLIST support for public-inbox.

I'm mostly logging this for the record, so it's easier to point at the missing feature rather than wonder why the review-o-matic skips over such CLs (e.g., https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3591058/comments/f8266795_f0d4cd01).

And even if we don't get non-patchwork support, it might be nice to post a comment about why review-o-matic couldn't handle the review.

Now that config scripts don't need chroot, resurrect the kconfig reviewer

From tfiga

I just noticed that it if one changes a patch from FROMGIT to UPSTREAM
and forgets to remove the maintainer's tree URL, Seanbot uses that URL
as the upstream link for the patch, rather than a proper link to
Linus' tree. I think it could also be useful to have it warn about the
issue.

An example CL where it happened:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2379934/9#message-a516047bca792f32076c39ba9689f0aab623ccfc

When uploading a BACKPORT patch, the bot gives a diff against the upstream patch, which is super convenient. However the diff is missing the file names, which can make it difficult to analyze. Example from https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1644482/4#message-3d1c6692e0e48871695b5416ab8c58a9da8293bb:

This patch differs from the source commit.

This is expected, and this message is posted to make reviewing backports easier.
  --- 
  +++ 
  @@ -123 +122,0 @@
  --	__u8	pad;
  @@ -142 +140,0 @@
  --	__u8	pad;
  @@ -157 +154,0 @@
  --	__u8	pad;
------------------

Maybe this is because the diff is made against the patches themselves?

If a gerrit fetch fails, it's very likely to be transient (since the patch appeared in a gerrit search), so don't blocklist these failures.

Avoids issues like https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3570337

E.g. https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4028479

the difference between Patchset 5 is only the base but the vote flipped from +1 to -1.

For reference: https://crrev.com/c/3503330

Patchset 1 was an old version of the patch on patchwork; the most recent version of the patch had addressed feedback from that version and had a Reviewed-By.

Feature request: Is it possible to query whether there are more recent revisions of a patch available and have review-o-matic either call this out in its auto review, or even give a CR-1?

Some projects might like feedback on patches without prefix

Example of validated patch:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1644481/2

Despite being an UPSTREAM CL, the cherry-picked line is as follows:

(cherry picked from commit c27bb30e7b6d385c5bff26406089377d678f1a1d
 git://linuxtv.org/media_tree.git)

The reference does exist in Linus' tree, so ultimately this is not a big issue, but we probably don't need the reference to the maintainer tree in that case. Maybe the bot should reject such patches?

FROMLIST patches should have UPSTREAM-TASK to track the upstream progress of the patch.

In https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1702621:

"""
...
Signed-off-by: Jonathan Cameron [email protected]
(cherry picked from commit eb7ecb5192b2dcf2992f39156aacf72f6e78eae3
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg)
...
""""

I get the error message:

"""
The commit hash(es) you've provided in your commit message could not be found
upstream. The following hash/remote/branch tuple(s) were tried:

eb7ecb5192b2dcf2992f39156aacf72f6e78eae3
from remote https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git branch togreg

Please double check your commit hash is valid in the upstream tree, and please
fully specify the remote tree and branch for FROMGIT changes (see below):

(cherry picked from commit <commit SHA>
 <remote git url> <remote git branch>)

"""

But the path does exist:

https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=togreg&id=eb7ecb5192b2dcf2992f39156aacf72f6e78eae3

So here I was planning to upstream a CL, but I uploaded it to gerrit as well for staging purposes. Added "TO-UPSTREAM:" tag so I don't forget and my intentions were clear:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2309331/1#message-b37fa7764bbc2ca7e5d0962e46784ea47d6402ec

Seanbot quickly -1d it, which I suppose it's not exactly wrong (I don't want it to land as is either). But it -1d it for the wrong reasons (It assumed it was already sent somewhere upstream and downstreamed wrong).

Let me know what you think.

This is a very common CR-1 vote, especially for cherry-picks (to release branches, etc.):

Your commit message is missing the following required field(s):
    Signed-off-by: xxx

I don't believe it provides much value. In fact, Signed-off-by is totally unnecessary on chromium-review:
https://chromium.googlesource.com/chromiumos/docs/+/HEAD/contributing.md#Signed_off_by
but it's useful for training people on the upstream flow (where it is required), and for interacting between the two.

Can we improve this, at least for some limited cases?

Possible cases, in no particular order:

1. using Gerrit's Cherry Pick feature (for release branches, etc.)
2. hitting the Gerrit "rebase" button (e.g., to break excess dependencies)
3. adding Disallow-Recycled-Builds (to help bots submit the change properly)
4. adding additional BUG=
5. fixing Cq-Depend
6. stacks of CLs collated from different uploaders

These are all things that might be done by non-original-uploaders, and yet have no real bearing on any S-o-b chain. Gerrit can easily-enough tell you that there were no changes to the code contents in many of these cases; they are just being moved around by essentially automated tools.

This appears to be the most-ignored CR-1 reason for merged CLs:
https://chromium-review.googlesource.com/q/label:code-review%253D-1%252Cseanpaul%2540chromium.org+project:chromiumos/third_party/kernel+is:merged

Examples pulled from that search:

• https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2813242
• https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3135032
• https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2534151
• https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3114374

Leaving CR-1's that people ignore causes divergence in expectations: some reviewers start to complain that there are CR-1's, and some just ignore it, because it doesn't make much sense, and people want to move on with their life.

Source patch: https://lore.kernel.org/all/[email protected]/

Gerrit patch: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3162403/1

It is never permissible to mix CHROMIUM with upstream prefixes. Add some logic to detect this and fail the review.

When reviewing FROMGIT/FROMLIST prefixed patches, check mainline for the patch and suggest re-labeling as UPSTREAM