patchwork-fdo issueshttps://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues2022-08-30T13:51:49Zhttps://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/46Ignore in-reply-to patches from someone who is not the submitter2022-08-30T13:51:49ZLucas De MarchiIgnore in-reply-to patches from someone who is not the submitterA common thing to do is to monitor our own patch series in patchwork. However if someone replies to your patch 1 (or 0, if it has a coverletter), that person becomes the submitter. I think the likelihood of having someone else replying t...A common thing to do is to monitor our own patch series in patchwork. However if someone replies to your patch 1 (or 0, if it has a coverletter), that person becomes the submitter. I think the likelihood of having someone else replying to your patch series with a new version of a patch is very low.
Another problem is that when someone replies with a diff, it's usually a suggestion of something that could be done in **addition**, not as a complete replacement to that patch. In that case patchwork would create a new revision of that series and get lost since the patches don't apply anymore.
So, I think the best thing to do is to ignore patches that have the in-reply-to set and it's from someone different than the original submitter (by following the in-reply-to chain).https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/44Document patchwork's assumptions/expectations about patch series2020-06-15T11:46:58ZArkadiusz HilerDocument patchwork's assumptions/expectations about patch seriesSo we have a nice, linkable document to present to people.
We could link to in in the series is incomplete / series looks strange messages to clarify things for people.So we have a nice, linkable document to present to people.
We could link to in in the series is incomplete / series looks strange messages to clarify things for people.https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/43Emails fail to parse with unknown encoding: unknown-8bit2020-06-26T09:29:00ZArkadiusz HilerEmails fail to parse with unknown encoding: unknown-8bit```
Traceback:
File "patchwork/bin/parsemail.py" in main
948. return parse_mail(mail)
File "patchwork/bin/parsemail.py" in parse_mail
805. project = find_project(mail)
File "patchwork/bin/parsemail.py" in find_project
...```
Traceback:
File "patchwork/bin/parsemail.py" in main
948. return parse_mail(mail)
File "patchwork/bin/parsemail.py" in parse_mail
805. project = find_project(mail)
File "patchwork/bin/parsemail.py" in find_project
125. (_, prefixes) = clean_subject(mail.get('Subject'))
File "patchwork/bin/parsemail.py" in clean_subject
640. subject = clean_header(subject)
File "patchwork/bin/parsemail.py" in clean_header
90. fragments = list(map(decode, decode_header(header)))
File "patchwork/bin/parsemail.py" in decode
85. return frag_str.decode(frag_encoding)
Exception Type: LookupError
Exception Value: unknown encoding: unknown-8bit
```
**Example offending email:** https://lists.freedesktop.org/archives/intel-gfx/2020-May/240360.html<br/>
**Reason:** `Subject: =?unknown-8bit?q?Re=3A_=5BIntel-gfx=5D__=E2=9C=97_Fi=2ECI=2EIGT=3A_failure_for_Consider_DBuf_bandwidth_when_calculating_CDCLK_=28rev18=29?=`<br/>
**Client:** `User-Agent: alot/0.8.1`https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/42REST: Allow specifying the page size2020-06-23T14:35:08ZMartin RoukalaREST: Allow specifying the page sizeThe current REST interface only allows getting 20 results per query, which leads to a lot of requests and poor performance when the network latency is high. Allowing a page size of 100 would still remain reasonable on the database and wo...The current REST interface only allows getting 20 results per query, which leads to a lot of requests and poor performance when the network latency is high. Allowing a page size of 100 would still remain reasonable on the database and would increase by 5x the loading time of a js-based tool to show latencies.
For some inspiration, here is what I did for cibuglog: https://gitlab.freedesktop.org/gfx-ci/cibuglog/-/blob/master/CIResults/rest_views.py#L27https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/41Manually sent revision after rerun-revision has "THIS SERIES REVISION IS A RE...2020-03-09T14:00:45ZPetri LatvalaManually sent revision after rerun-revision has "THIS SERIES REVISION IS A RERUN"If the re-test button is pressed, a new revision is created and the message "THIS SERIES REVISION IS A RERUN" is shown on it.
However, if a new revision is manually sent after that, even the new manual revision has "THIS SERIES REVISION...If the re-test button is pressed, a new revision is created and the message "THIS SERIES REVISION IS A RERUN" is shown on it.
However, if a new revision is manually sent after that, even the new manual revision has "THIS SERIES REVISION IS A RERUN".https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/40In series view, add more information about test warns/failures2020-07-17T10:59:49ZTomi SarvelaIn series view, add more information about test warns/failuresWhen the patchseries list is constructed, the worst test result is shown under "Tests", e.g. "Failure"
It would be nice to see on a glance which test failed the patchseries, e.g.
Fi.CI.BUILD (FAILURE) or
Fi.CI.BAT Fi.CI.IGT (WARNING)When the patchseries list is constructed, the worst test result is shown under "Tests", e.g. "Failure"
It would be nice to see on a glance which test failed the patchseries, e.g.
Fi.CI.BUILD (FAILURE) or
Fi.CI.BAT Fi.CI.IGT (WARNING)https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/39My email replies to patches end up empty in Patchwork2020-02-06T13:09:25ZPekka Paalanenppaalanen@gmail.comMy email replies to patches end up empty in PatchworkI rarely look at Patchwork for review discussions, but some time ago I noticed that perhaps all replies from me are recorded as empty messages.
An example: https://patchwork.freedesktop.org/patch/306044/ (The comment from Pekka Paalanen...I rarely look at Patchwork for review discussions, but some time ago I noticed that perhaps all replies from me are recorded as empty messages.
An example: https://patchwork.freedesktop.org/patch/306044/ (The comment from Pekka Paalanen.)
This is the email I sent: [pq-email.txt](/uploads/30cc5817756f057d4d6c0c2e6a01955b/pq-email.txt)https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/38Display number of comments on patches2020-02-04T08:48:57ZArkadiusz HilerDisplay number of comments on patches`<mlankhorst_> ivyl: hey, could you add a column to https://patchwork.freedesktop.org/series/72521/ AFRT with amount of comments on a patch?`
Templates/views that need changing:
* https://patchwork.freedesktop.org/project/igt/patches/
*...`<mlankhorst_> ivyl: hey, could you add a column to https://patchwork.freedesktop.org/series/72521/ AFRT with amount of comments on a patch?`
Templates/views that need changing:
* https://patchwork.freedesktop.org/project/igt/patches/
* patchwork.freedesktop.org/series/$ID/, e.g.: https://patchwork.freedesktop.org/series/70059/https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/37Display cover letter message-id on the patch series page2020-01-15T09:17:04ZJani NikulaDisplay cover letter message-id on the patch series pageThe patch page displays the message-id of the patch message. I would like to have the series page display the cover letter message-id as well.
For example, https://patchwork.freedesktop.org/series/70502/ should include "Message ID cover...The patch page displays the message-id of the patch message. I would like to have the series page display the cover letter message-id as well.
For example, https://patchwork.freedesktop.org/series/70502/ should include "Message ID cover.1575560168.git.jani.nikula@intel.com".https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/36Add support for referencing series using cover letter message-id2020-07-01T08:44:59ZJani NikulaAdd support for referencing series using cover letter message-idCurrently it's possible to reference **patches** using the message-id, for example http://patchwork.freedesktop.org/patch/msgid/600101c8433e7caf9303663fc85a9972fa1f05e7.1575560168.git.jani.nikula@intel.com will redirect to https://patchw...Currently it's possible to reference **patches** using the message-id, for example http://patchwork.freedesktop.org/patch/msgid/600101c8433e7caf9303663fc85a9972fa1f05e7.1575560168.git.jani.nikula@intel.com will redirect to https://patchwork.freedesktop.org/patch/343812/
I would like to be able to reference **patch series** using the cover letter message-id, and, additionally, using the message-id of any patch in the series.
For example, the following should redirect to https://patchwork.freedesktop.org/series/70502/
* https://patchwork.freedesktop.org/series/msgid/cover.1575560168.git.jani.nikula@intel.com
* http://patchwork.freedesktop.org/series/msgid/600101c8433e7caf9303663fc85a9972fa1f05e7.1575560168.git.jani.nikula@intel.com
* http://patchwork.freedesktop.org/series/msgid/c945ac7b08e0eb0827cf647609885f4abdb84f1d.1575560168.git.jani.nikula@intel.comhttps://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/35Add a visual indicator that results expand2020-01-10T11:12:28ZArkadiusz HilerAdd a visual indicator that results expand**Test are listed as follows on a series view ([example](https://patchwork.freedesktop.org/series/71801/#rev1)):**<br/>
![image](/uploads/cd1ac38d8c0fbf5bac5cddbac8a0b81a/image.png)
**If you click on the grey background some of those ex...**Test are listed as follows on a series view ([example](https://patchwork.freedesktop.org/series/71801/#rev1)):**<br/>
![image](/uploads/cd1ac38d8c0fbf5bac5cddbac8a0b81a/image.png)
**If you click on the grey background some of those expand showing more details:**
![image](/uploads/1b4476a804422dd9a82735f0a1e35874/image.png)
This is not obvious and it's not indicated in any way, therefore **we have to add a visual indicator**. Some kind of triangle pointed down in the right corner would work (:arrow_down_small:).
Note: Some of the results may not have body and should not have the indicator.https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/34Bad splitting of complex patch into commit message & diff2020-06-18T17:38:37ZArkadiusz HilerBad splitting of complex patch into commit message & diff**Found by:** @adrinael<br/>
**Offending patch:** [breaks-patchwork-parsing.txt](/uploads/1b91522ce59d6d90d710d435e905d128/breaks-patchwork-parsing.txt)<br/>
**Result:** https://patchwork.freedesktop.org/patch/347352/
The patch was not ...**Found by:** @adrinael<br/>
**Offending patch:** [breaks-patchwork-parsing.txt](/uploads/1b91522ce59d6d90d710d435e905d128/breaks-patchwork-parsing.txt)<br/>
**Result:** https://patchwork.freedesktop.org/patch/347352/
The patch was not parsed/split correctly and large chunk of the diff ends up in the commit message instead of the patch body making the whole thing not appliable.
Patchwork splits email into commit message and the patch body. This is done so tags from the comments (e.g. reviewed-by) can be appended to the resulting mbox.
The issue seems to be in [`patch_parse()`](https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/blob/master/patchwork/parser.py#L34) which is handling the splitting.https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/33Patchwork does not support certain unprintable characters in patches2020-07-07T11:42:36ZArkadiusz HilerPatchwork does not support certain unprintable characters in patchesThe initial assessment was wrong. Patchwork seems to handle multipart emails just fine and extracts the patch just fine. The issue at hand is how patchwork is unable to deal with unprintable characters.
**Example:** [multipart.txt](/upl...The initial assessment was wrong. Patchwork seems to handle multipart emails just fine and extracts the patch just fine. The issue at hand is how patchwork is unable to deal with unprintable characters.
**Example:** [multipart.txt](/uploads/c5c0159c183e7380bbc7943df6721b17/multipart.txt)https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/32Make sure that we don't duplicate Person instances with the *same-ish* email2020-07-15T11:51:33ZArkadiusz HilerMake sure that we don't duplicate Person instances with the *same-ish* emailPatchwork keeps attribution of patches by assigning them to a `Person` model - something that is looked up / created basing on the email.
In [`find_author()`](https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/blob/master/patc...Patchwork keeps attribution of patches by assigning them to a `Person` model - something that is looked up / created basing on the email.
In [`find_author()`](https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/blob/master/patchwork/bin/parsemail.py#L176) we look for a Person instance basing on their email:
```python
person = Person.objects.get(email__iexact=email)
```
Sometimes we get:
```
Exception Type: MultipleObjectsReturned
Exception Value: get() returned more than one Person -- it returned 2!
Request data not supplied
```
This may happen if user sent us multiple messages with varying casing of their email-address in the "From" field. Common example would be: Name.Surname@example.com vs name.surname@example.com
**Which leaves us with discarded emails...**
[RFC5321](https://tools.ietf.org/html/rfc5321#section-2.4) and [RFC2822](https://tools.ietf.org/html/rfc2822#section-3.4.1) just vaguely states that the local-part is up to interpretation by the host and:
> However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.
**Tough call time:** since most email services seem to treat the local-part as case-insensitive we should de-duplicate on our side.
Sadly there seems to be no sane way of having case insensitive fields or adding case insensitive unique constraint via Django.
**TODO:**
* [ ] figure out where were we `save()`-ing Persons with different email capitalization without trying to look for them first
* [ ] converge on using lowercase everywhere, e.g. via [`Model.clean()`](https://docs.djangoproject.com/en/2.2/ref/models/instances/#django.db.models.Model.clean)
* [ ] create a migration that deduplicates users
* [ ] write tests for the abovehttps://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/31Revision wrongly marked as rerun2020-03-09T15:01:19ZArkadiusz HilerRevision wrongly marked as rerunhttps://patchwork.freedesktop.org/series/66806/
rev4 is not a rerun, it came from the mailing list (just compare it with rev3)
I am not sure whether this happened when merging or when patchwork picked up the patch, but this shouldn't b...https://patchwork.freedesktop.org/series/66806/
rev4 is not a rerun, it came from the mailing list (just compare it with rev3)
I am not sure whether this happened when merging or when patchwork picked up the patch, but this shouldn't be the case.
We need to write a test that reproduces this and fix it.https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/30Improve link to patchwork's homepage2021-07-10T16:43:57ZArkadiusz HilerImprove link to patchwork's homepageWhen viewing patch/series/series-list/etc the upper left corner is a link back to the patchwork's home-page.
![image](/uploads/07513a5880f9536ed87170289f0d2892/image.png)
The issues is that the whole "Patchwork X.Org" is a single link ...When viewing patch/series/series-list/etc the upper left corner is a link back to the patchwork's home-page.
![image](/uploads/07513a5880f9536ed87170289f0d2892/image.png)
The issues is that the whole "Patchwork X.Org" is a single link that just takes you to `/`. This inconsistent with modern UX principles and confuses people - some expect that this the "X.Org" part will take them to the project page.
This should be split so that "Patchwork" takes you to `/` and the project name (e.g. "X.Org") takes you to the project's landing page page (e.g. `/project/Xorg/`) or is un-clickable and uses different shade of gray for background.https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/29Reflect the filters in the URL for the series view2020-06-23T12:27:37ZArkadiusz HilerReflect the filters in the URL for the series viewWhenever we filter on the patch view, the filters are reflected in the current URL (window.location) which makes them shareable and bookmarkable. E.g.: https://patchwork.freedesktop.org/project/intel-gfx/patches/?submitter=5895
The same...Whenever we filter on the patch view, the filters are reflected in the current URL (window.location) which makes them shareable and bookmarkable. E.g.: https://patchwork.freedesktop.org/project/intel-gfx/patches/?submitter=5895
The same is not true for series view (e.g. https://patchwork.freedesktop.org/project/intel-gfx/series/).
The used filtering mechanism seems to be different and UX is inconsistent. Let's fix that!https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/28FDO deployment fails to parse a pull request2019-10-21T11:20:32ZArkadiusz HilerFDO deployment fails to parse a pull requestThe mail parses and shows up just fine with local instance of patchwork,
not with the FDO deployed one:
```
patchwork@emeril:/tmp$ /srv/patchwork.freedesktop.org/patchwork/bin/parsemail.sh --verbosity debug < ttm
Message-Id is <1eba1bc0...The mail parses and shows up just fine with local instance of patchwork,
not with the FDO deployed one:
```
patchwork@emeril:/tmp$ /srv/patchwork.freedesktop.org/patchwork/bin/parsemail.sh --verbosity debug < ttm
Message-Id is <1eba1bc0-ba0c-b948-6a3d-51a98f4e5c27@gmail.com>
```
Yet https://patchwork.freedesktop.org/patch/msgid/1eba1bc0-ba0c-b948-6a3d-51a98f4e5c27@gmail.com yields no results.
The only difference is that patchwork.fdo runs on Python 2.7 and the local one uses Python 3. I'll downgrade locally to try to reproduce. If that's the reason I was planning onto upgrading to Python 3 anyway :-)
Affected email: [ttm-pull.mail](/uploads/1b7c672f466857bcd6a687d1334758d0/ttm-pull.mail)Arkadiusz HilerArkadiusz Hilerhttps://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/27"skip testing" button2021-07-10T16:43:57ZArkadiusz Hiler"skip testing" buttonSomething like:
![image](/uploads/97644d07e06a9b3eba478edd2ac35ae1/image.png)
how it would work:
POST to `/series/{sid}/revisions/{rid}/skiptesting`
This would require following changes:
```diff
diff --git a/patchwork/models.py b/patc...Something like:
![image](/uploads/97644d07e06a9b3eba478edd2ac35ae1/image.png)
how it would work:
POST to `/series/{sid}/revisions/{rid}/skiptesting`
This would require following changes:
```diff
diff --git a/patchwork/models.py b/patchwork/models.py
index 627dd2b..8b882a6 100644
--- a/patchwork/models.py
+++ b/patchwork/models.py
@@ -625,6 +625,7 @@ class SeriesRevision(models.Model):
state_summary = jsonfield.JSONField(null=True)
test_state = models.SmallIntegerField(choices=TestState.STATE_CHOICES,
null=True, blank=True)
+ skip_testing = models.BooleanField(default=False)
class Meta:
unique_together = [('series', 'version')]
diff --git a/patchwork/views/api.py b/patchwork/views/api.py
index 28dba80..df53952 100644
--- a/patchwork/views/api.py
+++ b/patchwork/views/api.py
@@ -321,6 +321,18 @@ class RevisionViewSet(mixins.ListModelMixin, ListMixin,
log.save()
return HttpResponse()
+ @detail_route(methods=['post'])
+ def skiptesting(self, request, series_pk=None, pk=None):
+ rev = get_object_or_404(SeriesRevision, series=series_pk, version=pk)
+
+ # make sure the user is a maintainer
+ self.check_object_permissions(request, rev.series)
+
+ rev.skip_testing = True
+ rev.save()
+
+ return HttpResponse()
+
class ResultMixin(object):
```
Then it would be for any CI system that manages exection to query `/series/{sid}/revisions/{rid}` before any stage of execution to see whether the run is still valid (i.e. not skipped).
Let's also be explicit that the series is already marked as skipped via `<button disabled class="btn btn-danger">`:
![image](/uploads/5a73eb2b2c2fb9df22c7454eee43cd5f/image.png)Arkadiusz HilerArkadiusz Hilerhttps://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/issues/26git-pw fails to get the config in a worktree setup2019-07-26T06:46:39ZLucas De Marchigit-pw fails to get the config in a worktree setupBy using dim to create the checkout of the kernel tree, I have the following dir structure:
```
[ldmartin@ldmartin-desk1 src]$ git worktree list
linux-dim/src 4fd955732d1e [tip-tgl-batch3-v2]
linux-dim/drm-inte...By using dim to create the checkout of the kernel tree, I have the following dir structure:
```
[ldmartin@ldmartin-desk1 src]$ git worktree list
linux-dim/src 4fd955732d1e [tip-tgl-batch3-v2]
linux-dim/drm-intel-fixes d7e8a19b38c8 [drm-intel-fixes]
linux-dim/drm-intel-next a17ce803dffa [drm-intel-next]
linux-dim/drm-intel-next-fixes c36beba6b296 [drm-intel-next-fixes]
linux-dim/drm-intel-next-queued 5cad0ddf4b78 [drm-intel-next-queued]
linux-dim/drm-misc-fixes 2f040d27080d [drm-misc-fixes]
linux-dim/drm-misc-next 1e9907362453 [drm-misc-next]
linux-dim/drm-misc-next-fixes 7aaddd96d5fe [drm-misc-next-fixes]
linux-dim/drm-rerere bf599a557a56 [rerere-cache]
linux-dim/drm-tip 40ef4755f8a1 [drm-tip]
linux-dim/topic/core-for-CI 3acdd1462f96 [topic/core-for-CI]
linux-dim/topic/remove-fbcon-notifiers 6116b892bd4f [topic/remove-fbcon-notifiers]
```
`src` is the "main tree".
This works:
```
[ldmartin@ldmartin-desk1 src]$ cd src
[ldmartin@ldmartin-desk1 src]$ git config --get patchwork.default.project
intel-gfx
```
This works:
```
[ldmartin@ldmartin-desk1 src]$ cd drm-intel-next-queued
[ldmartin@ldmartin-desk1 drm-intel-next-queued]$ git config --get patchwork.default.project
intel-gfx
```
This doesn't:
```
[ldmartin@ldmartin-desk1 drm-intel-next-queued]$ git pw mbox 63670
fatal: git-pw isn't configured.
Please set up the patchwork url and project, e.g.:
git config patchwork.default.url https://patchwork.freedesktop.org
git config patchwork.default.project intel-gfx
```
It seems to be a bug in GitPython to get the config in a worktree setup?