Re: [PATCH] Disable i18n machinery, use correct locale

2019-12-01 Thread Andrew Donnellan
On 8/11/19 1:01 am, Daniel Axtens wrote: Stephen Finucane writes: Two issues here. Firstly, the use of the 'USE_I18N'. The Django docs describe this as such: A boolean that specifies whether Django’s translation system should be enabled. This provides an easy way to turn it off, for

[PATCH v4 2/3] parser: Use a second query to weed out duplicate series

2019-12-01 Thread Stephen Finucane
Annoyingly, not all email clients properly thread emails using the message ID fields originally specified in RFC 822 [1]. Worse, some MTAs (cough, outlook.com, cough) actually override what the client configures, breaking the world in the process. Realising this is an issue, Patchwork supports

[PATCH v4 3/3] tests: Add test for broken parser

2019-12-01 Thread Stephen Finucane
Add tests for the recent changes we made to how we parse multiple series received at once. These tests actually highlighted what appeared to be the test failure that's been intermittently breaking our CI for years now, so the 'expectedFailure' marker has been removed in the hope that this is

[PATCH v4 1/3] models: Use database constraints to prevent split Series

2019-12-01 Thread Stephen Finucane
Currently, the 'SeriesReference' object has a unique constraint on the two fields it has, 'series', which is a foreign key to 'Series', and 'msgid'. This is the wrong constraint. What we actually want to enforce is that a patch, cover letter or comment is referenced by a single series, or rather a

[PATCH 1/2] settings: Add configuration for sqlite DB backend

2019-12-01 Thread Stephen Finucane
Signed-off-by: Stephen Finucane --- patchwork/settings/dev.py | 7 +++ 1 file changed, 7 insertions(+) diff --git a/patchwork/settings/dev.py b/patchwork/settings/dev.py index e110e745..c5afe0d5 100644 --- a/patchwork/settings/dev.py +++ b/patchwork/settings/dev.py @@ -51,6 +51,13 @@

[PATCH 2/2] tests: Skip tests that fail on SQLite DB backend

2019-12-01 Thread Stephen Finucane
These are failing due to differences in behavior of the backend. Since this will never be used for production, we can simply skip these unit tests and rely on the CI to catch potential issues. Signed-off-by: Stephen Finucane --- patchwork/tests/test_list.py | 13 + 1 file changed,

Re: [PATCH v4 0/4] Store the 'actor' responsible for events

2019-12-01 Thread Johan Herland
On Sun, Dec 1, 2019 at 1:11 PM Stephen Finucane wrote: > Thanks for the quick turnaround on this. I squashed patches 3 and 4, > added a release note, fixed a minor issue with the schema documentation > and pushed everything. It will form part of Patchwork v2.2 which I'm > hoping to get out this

Re: [PATCH v4 4/4] /api/events: Allow filtering by 'actor' field

2019-12-01 Thread Stephen Finucane
On Sun, 2019-12-01 at 02:49 +0100, Johan Herland wrote: > Cc: Mauro Carvalho Chehab > Suggested-by: Stephen Finucane > Signed-off-by: Johan Herland Squashed with patch 3, but... Reviewed-by: Stephen Finucane > --- > patchwork/api/filters.py | 5 - >

Re: [PATCH v4 3/4] /api/events: Add 'actor' field to generated JSON

2019-12-01 Thread Stephen Finucane
On Sun, 2019-12-01 at 02:49 +0100, Johan Herland wrote: > Cc: Mauro Carvalho Chehab > Signed-off-by: Johan Herland > Acked-by: Daniel Axtens Applied with the minor tweaks noted below. Reviewed-by: Stephen Finucane > --- > docs/api/schemas/latest/patchwork.yaml | 6 ++ >

Re: [PATCH v4 2/4] Include the responsible actor in applicable events

2019-12-01 Thread Stephen Finucane
On Sun, 2019-12-01 at 02:49 +0100, Johan Herland wrote: > We want to use the events as an audit log. An important part of this is > recording _who_ made the changes that the events represent. > > To accomplish this, we need to know the current user (aka. request.user) > at the point where we

Re: [PATCH v4 0/4] Store the 'actor' responsible for events

2019-12-01 Thread Stephen Finucane
On Sun, 2019-12-01 at 02:49 +0100, Johan Herland wrote: > The V4L project (https://patchwork.linuxtv.org) uses patch states and > delegates extensively to track progress. We want an audit log to keep > track of the changes made to these patch fields. The Event model already > records this