Re: [PATCH] Allow ordering events by date

Stephen Finucane writes: > On Tue, 2019-10-15 at 17:30 -0400, Jeremy Cline wrote: >> By default, the events API orders events by date in descending order >> (newest first). However, it's useful to be able to order the events by >> oldest events first. For example, when a client is polling the eve

Re: [PATCH v3 0/3] Store the 'actor' responsible for events

Johan Herland writes: > 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 information, but leaves out one crucial d

Re: [PATCH 3/3] [PW3] Remove XML-RPC API

Stephen Finucane writes: > On Fri, 2019-10-18 at 13:41 +1100, Daniel Axtens wrote: >> It's been deprecated since 2.0 with the new REST API. That API is >> now pretty solid, and git-pw is good. Drop the old API. >> >> Provide a page letting people know that the API is gone if they >> access any o

Re: Patchwork 3 branch

On Fri, 2019-10-18 at 14:21 +1100, Daniel Axtens wrote: > Hi all, > > We're getting pretty close to a 2.2 release, but there's a few things > kicking around already that I want to consider for patchwork 3. I don't > want to delay 2.2 forever and squeeze everything in, but I also don't > want the p

Re: [PATCH 3/3] [PW3] Remove XML-RPC API

On Fri, 2019-10-18 at 13:41 +1100, Daniel Axtens wrote: > It's been deprecated since 2.0 with the new REST API. That API is > now pretty solid, and git-pw is good. Drop the old API. > > Provide a page letting people know that the API is gone if they > access any of the old pages. > > This breaks

Re: [PATCH v2] parser: Unmangle From: headers that have been mangled for DMARC purposes

Applied with a release note. Daniel Axtens writes: > Andrew Donnellan writes: > >> To avoid triggering spam filters due to failed signature validation, many >> mailing lists mangle the From header to change the From address to be the >> address of the list, typically where the sender's domain h

Re: [PATCH 1/3] docs: document snowpatch as an API client

Stephen Finucane writes: > On Fri, 2019-10-18 at 13:41 +1100, Daniel Axtens wrote: >> Snowpatch is one of the few publically visible API clients. >> Document it in the clients list. >> >> Signed-off-by: Daniel Axtens > > This can go in as part of 2.2, IMO. There's nothing specific to the > XML-

Re: [PATCH v2] parser: Unmangle From: headers that have been mangled for DMARC purposes

On Fri, 2019-10-18 at 15:16 +1100, Andrew Donnellan wrote: > On 18/10/19 3:06 pm, Daniel Axtens wrote: > > I'll apply it shortly to master. You could convince me to get it > > backported to stable if you really wanted. > > > > Do we need something to go through the db and fix up old ones? Or is it

Re: [PATCH 2/3] docs: bump the copyright year in the docs

On Fri, 2019-10-18 at 13:41 +1100, Daniel Axtens wrote: > It's 2019. It's almost 2020, in fact! > > Signed-off-by: Daniel Axtens This one too. Reviewed-by: Stephen Finucane > --- > docs/conf.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git docs/conf.py docs/conf.py

Re: [PATCH 1/3] docs: document snowpatch as an API client

On Fri, 2019-10-18 at 13:41 +1100, Daniel Axtens wrote: > Snowpatch is one of the few publically visible API clients. > Document it in the clients list. > > Signed-off-by: Daniel Axtens This can go in as part of 2.2, IMO. There's nothing specific to the XML-RPC API removal in here. Reviewed-by:

Re: [PATCH v2] models: Use database constraints to prevent split Series

On Fri, 2019-10-18 at 09:48 +1100, Daniel Axtens wrote: > Hi Stephen, > > Were you aiming this for 2.2 or for 3? > > I'm thinking 3 but happy to be convinced otherwise. I'd personally like this to be a blocker for v2.2, though the Python 3 part of the migration can possibly be dropped (I can res

Re: [PATCH] tests: Rename inaccurately named test_patchwork_from_header

Andrew Donnellan writes: > On 18/10/19 3:02 pm, Daniel Axtens wrote: >> Andrew Donnellan writes: >> >>> The test_patchwork_from_header test claims to test for the presence of the >>> X-Patchwork-From header, when we actually call it X-Patchwork-Sender. >> X-Patchwork-Submitter, surely? > > Wow,

Re: [PATCH v2] parser: Unmangle From: headers that have been mangled for DMARC purposes

On 18/10/19 3:06 pm, Daniel Axtens wrote: I'll apply it shortly to master. You could convince me to get it backported to stable if you really wanted. Do we need something to go through the db and fix up old ones? Or is it best to let sleeping patches lie? Personally I was thinking we should leav

Re: [PATCH] tests: Rename inaccurately named test_patchwork_from_header

On 18/10/19 3:02 pm, Daniel Axtens wrote: Andrew Donnellan writes: The test_patchwork_from_header test claims to test for the presence of the X-Patchwork-From header, when we actually call it X-Patchwork-Sender. X-Patchwork-Submitter, surely? Wow, the irony of me getting this wrong in the c

Re: [PATCH v2] parser: Unmangle From: headers that have been mangled for DMARC purposes

Andrew Donnellan writes: > To avoid triggering spam filters due to failed signature validation, many > mailing lists mangle the From header to change the From address to be the > address of the list, typically where the sender's domain has a strict DMARC > policy enabled. > > In this case, we sho

Re: [PATCH] tests: Rename inaccurately named test_patchwork_from_header

Andrew Donnellan writes: > The test_patchwork_from_header test claims to test for the presence of the > X-Patchwork-From header, when we actually call it X-Patchwork-Sender. X-Patchwork-Submitter, surely? (I didn't even know that one existed!) Regards, Daniel > > Fix it. > > Signed-off-by: Andr

[PATCH] tests: Rename inaccurately named test_patchwork_from_header

The test_patchwork_from_header test claims to test for the presence of the X-Patchwork-From header, when we actually call it X-Patchwork-Sender. Fix it. Signed-off-by: Andrew Donnellan --- patchwork/tests/test_mboxviews.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/

Patchwork 3 branch

Hi all, We're getting pretty close to a 2.2 release, but there's a few things kicking around already that I want to consider for patchwork 3. I don't want to delay 2.2 forever and squeeze everything in, but I also don't want the patches to rot while we sort out the final 2.2 stuff. So I'm startin

[PATCH 3/3] [PW3] Remove XML-RPC API

It's been deprecated since 2.0 with the new REST API. That API is now pretty solid, and git-pw is good. Drop the old API. Provide a page letting people know that the API is gone if they access any of the old pages. This breaks pwclient, which only supports the old API. So we delete a few things t

[PATCH 1/3] docs: document snowpatch as an API client

Snowpatch is one of the few publically visible API clients. Document it in the clients list. Signed-off-by: Daniel Axtens --- docs/usage/clients.rst | 13 + 1 file changed, 13 insertions(+) diff --git docs/usage/clients.rst docs/usage/clients.rst index 57c8a1a14a4d..01dd62a28e50 100

[PATCH 2/3] docs: bump the copyright year in the docs

It's 2019. It's almost 2020, in fact! Signed-off-by: Daniel Axtens --- docs/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git docs/conf.py docs/conf.py index f0ca797f6dac..646db889e731 100644 --- docs/conf.py +++ docs/conf.py @@ -34,7 +34,7 @@ master_doc = 'index' # Ge

[PATCH 0/3] [PW3] Remove XML-RPC API

Two small doc changes, then a big patch dropping the XML-RPC API, and everything related to pwclient, for Patchwork 3. Daniel Axtens (3): docs: document snowpatch as an API client docs: bump the copyright year in the docs [PW3] Remove XML-RPC API docs/TODO

Re: [PATCH v2] models: Use database constraints to prevent split Series

Hi Stephen, > 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

Re: [PATCH v2] models: Use database constraints to prevent split Series

Hi Stephen, Were you aiming this for 2.2 or for 3? I'm thinking 3 but happy to be convinced otherwise. I'll also open a topic branch for PW3 and start posting some of my Python 2 removal patches. Regards, Daniel > Currently, the 'SeriesReference' object has a unique constraint on the > two fie

Re: [PATCH] Allow ordering events by date

On Thu, 2019-10-17 at 14:19 +, Jeremy Cline wrote: > On Thu, Oct 17, 2019 at 03:09:16PM +0100, Stephen Finucane wrote: > > On Thu, 2019-10-17 at 09:35 -0400, Jeremy Cline wrote: > > > On Thu, Oct 17, 2019 at 02:07:28PM +0100, Stephen Finucane wrote: > > > > On Tue, 2019-10-15 at 17:30 -0400, Je

Re: [PATCH 3/5] models, templates: Add sumbission relations

Just to point out the typo: s/sumbission/submission/ in the commit message header. Lukas ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH] Allow ordering events by date

On Thu, Oct 17, 2019 at 03:09:16PM +0100, Stephen Finucane wrote: > On Thu, 2019-10-17 at 09:35 -0400, Jeremy Cline wrote: > > On Thu, Oct 17, 2019 at 02:07:28PM +0100, Stephen Finucane wrote: > > > On Tue, 2019-10-15 at 17:30 -0400, Jeremy Cline wrote: > > > > By default, the events API orders eve

Re: [PATCH] Allow ordering events by date

On Thu, 2019-10-17 at 09:35 -0400, Jeremy Cline wrote: > On Thu, Oct 17, 2019 at 02:07:28PM +0100, Stephen Finucane wrote: > > On Tue, 2019-10-15 at 17:30 -0400, Jeremy Cline wrote: > > > By default, the events API orders events by date in descending order > > > (newest first). However, it's useful

Re: [PATCH] Allow ordering events by date

On Thu, Oct 17, 2019 at 02:07:28PM +0100, Stephen Finucane wrote: > On Tue, 2019-10-15 at 17:30 -0400, Jeremy Cline wrote: > > By default, the events API orders events by date in descending order > > (newest first). However, it's useful to be able to order the events by > > oldest events first. For

Re: [PATCH] Allow ordering events by date

On Tue, 2019-10-15 at 17:30 -0400, Jeremy Cline wrote: > By default, the events API orders events by date in descending order > (newest first). However, it's useful to be able to order the events by > oldest events first. For example, when a client is polling the events > API for new events since a

Re: [PATCH] Use secrets and fall back to random.SystemRandom for keys

On Wed, 2019-10-09 at 18:55 -0400, Jeremy Cline wrote: > On Thu, Oct 10, 2019 at 09:32:13AM +1100, Daniel Axtens wrote: > > > diff --git > > > a/releasenotes/notes/use-secrets-and-fall-back-to-random.SystemRandom-for-keys-9ceb496919a1bb6f.yaml > > > > > > b/releasenotes/notes/use-secrets-and-fal

Re: [PATCH v2 1/3] docker: Rely on caching

On Thu, 2019-10-17 at 11:34 +0100, Stephen Finucane wrote: > It seems less likely that tox and tox-pyenv will change than our > requirements. Split up the 'RUN' steps so we don't have to reinstall the > former every time the latter change. > > Signed-off-by: Stephen Finucane Test only change. Ev

Re: [PATCH 1/3] docker: Rely on caching

On Wed, 2019-10-16 at 21:33 +0200, Geert Stappers wrote: > On 16-10-2019 14:10, Stephen Finucane wrote: > > > It seems less likely that tox and tox-pyenv will change than our > > requirements. Split up the 'RUN' steps so we don't have to reinstall the > > former every time the latter change. > >

[PATCH v2] models: Use database constraints to prevent split Series

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 v2 1/3] docker: Rely on caching

It seems less likely that tox and tox-pyenv will change than our requirements. Split up the 'RUN' steps so we don't have to reinstall the former every time the latter change. Signed-off-by: Stephen Finucane --- tools/docker/Dockerfile | 11 +-- 1 file changed, 5 insertions(+), 6 deletion

[PATCH v2 2/3] docker: Ignore .tox, .backups directories

These can be _huge_ which can significantly slow down the startup time. We don't need them so ignore them. Signed-off-by: Stephen Finucane --- .dockerignore | 2 ++ 1 file changed, 2 insertions(+) diff --git .dockerignore .dockerignore index 216f4ba2..77feb067 100644 --- .dockerignore +++ .dock

[PATCH v2 3/3] docker: Require GID also

If you don't do this, created files end up with a group of 'gcc' or whatever group has an ID of 1000. Signed-off-by: Stephen Finucane --- docker-compose.yml | 2 ++ tools/docker/Dockerfile | 11 +++ 2 files changed, 9 insertions(+), 4 deletions(-) diff --git docker-compose.yml doc