Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs?
On 1/7/19 11:35 am, Andrew Donnellan wrote: On 1/7/19 2:01 am, Mauro Carvalho Chehab wrote: Em Sat, 29 Jun 2019 12:20:55 +0100 Mark Brown escreveu: On Sat, Jun 29, 2019 at 09:18:28AM +0200, Takashi Iwai wrote: BTW, can the URL be reached from patchwork? That'd be really handy. Even better, could patchwork add it to the mboxes you download from it like acks and so on? Currently you can get the message ID so it's easy to construct the link for things that are on LKML. I'm all for it, but the problem with patchwork is that the tool may be used on non-kernel development and/or the ML may not be in lore. Also, there are more than one patchwork instance. We use our own for Linux media (https://patchwork.linuxtv.org)[1]. On media, patchwork is used for both Kernel development and VDR development (an userspace tool) - with is a completely unrelated project (with different people behind it - and even a different mailing list). So, whatever change at patchwork should be done in a way that the ML URL could be customized, and the new field would be added only if the URL is not blank. [+ patchwork list] I'll have a go at adding a project/list-specific archive prefix and exposing that in the web interface. I've now submitted patches to add a mailing list archive link for each patch visible via the web interface and also via the REST API. Regarding adding it to downloaded mboxes, if we do that I'd like it to be a separate option. A single patch can also land in patchwork multiple times via various lists, so the URL will depend on which project you're looking at. Haven't done this bit yet. -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
[PATCH 5/6] docs: Add API v1.2
Add API v1.2, including the new fields for list archive URLs. Signed-off-by: Andrew Donnellan --- docs/api/rest/index.rst| 11 +- docs/api/rest/schemas/v1.1.rst |4 +- docs/api/rest/schemas/v1.2.rst |5 + docs/api/schemas/generate_schema.py|4 +- docs/api/schemas/latest/patchwork.yaml | 59 +- docs/api/schemas/patchwork.j2 | 71 + docs/api/schemas/v1.2/patchwork.yaml | 2371 7 files changed, 2518 insertions(+), 7 deletions(-) create mode 100644 docs/api/rest/schemas/v1.2.rst create mode 100644 docs/api/schemas/v1.2/patchwork.yaml diff --git a/docs/api/rest/index.rst b/docs/api/rest/index.rst index 1a094d732594..d1169e56e07a 100644 --- a/docs/api/rest/index.rst +++ b/docs/api/rest/index.rst @@ -33,6 +33,11 @@ If all you want is reference guides, skip straight to :ref:`rest-api-schemas`. The API version was bumped to v1.1 in Patchwork v2.1. The older v1.0 API is still supported. For more information, refer to :ref:`rest-api-versions`. +.. versionchanged:: 2.2 + + The API version was bumped to v1.2 in Patchwork v2.2. The older APIs are + still supported. For more information, refer to :ref:`rest-api-versions`. + Getting Started --- @@ -98,7 +103,7 @@ Versioning -- By default, all requests will receive the latest version of the API: currently -``1.1``: +``1.2``: .. code-block:: http @@ -109,7 +114,7 @@ changes breaking your application: .. code-block:: http -GET /api/1.1 HTTP/1.1 +GET /api/1.2 HTTP/1.1 Older API versions will be deprecated and removed over time. For more information, refer to :ref:`rest-api-versions`. @@ -263,6 +268,7 @@ Supported Versions 1.0, 2.0, ✓ 1.1, 2.1, ✓ + 1.2, 2.2, ✓ Further information about this and more can typically be found in :doc:`the release notes `. @@ -278,6 +284,7 @@ Auto-generated schema documentation is provided below. /api/rest/schemas/v1.0 /api/rest/schemas/v1.1 + /api/rest/schemas/v1.2 .. Links diff --git a/docs/api/rest/schemas/v1.1.rst b/docs/api/rest/schemas/v1.1.rst index e18f81322688..1189f31571a5 100644 --- a/docs/api/rest/schemas/v1.1.rst +++ b/docs/api/rest/schemas/v1.1.rst @@ -1,5 +1,5 @@ -API v1.1 (latest) -= +API v1.1 + .. openapi:: ../../schemas/v1.1/patchwork.yaml :examples: diff --git a/docs/api/rest/schemas/v1.2.rst b/docs/api/rest/schemas/v1.2.rst new file mode 100644 index ..8a96519b7356 --- /dev/null +++ b/docs/api/rest/schemas/v1.2.rst @@ -0,0 +1,5 @@ +API v1.2 (latest) += + +.. openapi:: ../../schemas/v1.2/patchwork.yaml + :examples: diff --git a/docs/api/schemas/generate_schema.py b/docs/api/schemas/generate_schema.py index 39f5cf06a9e9..d4645d1f53fe 100644 --- a/docs/api/schemas/generate_schema.py +++ b/docs/api/schemas/generate_schema.py @@ -5,8 +5,8 @@ import os import jinja2 ROOT_DIR = os.path.dirname(os.path.realpath(__file__)) -VERSIONS = [(1, 0), (1, 1), None] -LATEST_VERSION = (1, 1) +VERSIONS = [(1, 0), (1, 1), (1, 2), None] +LATEST_VERSION = (1, 2) def generate_schema(): diff --git a/docs/api/schemas/latest/patchwork.yaml b/docs/api/schemas/latest/patchwork.yaml index 724b05ebf1b3..92f352f3e926 100644 --- a/docs/api/schemas/latest/patchwork.yaml +++ b/docs/api/schemas/latest/patchwork.yaml @@ -12,7 +12,7 @@ info: license: name: GPL v2 License url: https://www.gnu.org/licenses/gpl-2.0.html - version: '1.1' + version: '1.2' paths: /api/: get: @@ -1368,6 +1368,11 @@ components: readOnly: true minLength: 1 maxLength: 255 +list_archive_url: + title: List archive URL + type: string + readOnly: true + nullable: true date: title: Date type: string @@ -1418,6 +1423,11 @@ components: readOnly: true minLength: 1 maxLength: 255 +list_archive_url: + title: List archive URL + type: string + readOnly: true + nullable: true date: title: Date type: string @@ -1631,6 +1641,11 @@ components: readOnly: true minLength: 1 maxLength: 255 +list_archive_url: + title: List archive URL + type: string + readOnly: true + nullable: true date: title: Date type: string @@ -1863,6 +1878,22 @@ components: type: string readOnly: true maxLength: 64 +list_archive_url: + title: List archive URL + type: string + format: uri + maxLength: 2000 + nullable: true +list_archive_lookup_prefix: + title: List archive lookup prefix + type: string + format: uri + maxLength: 2000 + nullable: true + description: > +URL prefix
Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs?
On 1/7/19 2:01 am, Mauro Carvalho Chehab wrote: Em Sat, 29 Jun 2019 12:20:55 +0100 Mark Brown escreveu: On Sat, Jun 29, 2019 at 09:18:28AM +0200, Takashi Iwai wrote: BTW, can the URL be reached from patchwork? That'd be really handy. Even better, could patchwork add it to the mboxes you download from it like acks and so on? Currently you can get the message ID so it's easy to construct the link for things that are on LKML. I'm all for it, but the problem with patchwork is that the tool may be used on non-kernel development and/or the ML may not be in lore. Also, there are more than one patchwork instance. We use our own for Linux media (https://patchwork.linuxtv.org)[1]. On media, patchwork is used for both Kernel development and VDR development (an userspace tool) - with is a completely unrelated project (with different people behind it - and even a different mailing list). So, whatever change at patchwork should be done in a way that the ML URL could be customized, and the new field would be added only if the URL is not blank. [+ patchwork list] I'll have a go at adding a project/list-specific archive prefix and exposing that in the web interface. Regarding adding it to downloaded mboxes, if we do that I'd like it to be a separate option. A single patch can also land in patchwork multiple times via various lists, so the URL will depend on which project you're looking at. -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs?
On Mon, Jul 01, 2019 at 11:35:48AM +1000, Andrew Donnellan wrote: > Regarding adding it to downloaded mboxes, if we do that I'd like it to be a > separate option. A single patch can also land in patchwork multiple times > via various lists, so the URL will depend on which project you're looking > at. At least for the kernel there's a redirector lore.kernel.org/r/msgid which is list agnostic. I'm not sure it matters much which of muiltiple list archives get used though, if people really want this presumably just having any old link should be enough. signature.asc Description: PGP signature ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Add an script to generate patchwork stats
It could be useful to be able to see how many patches a patchwork
instance has. This small script does that.
We're using it to maintain a page with includes the generated stats at:
https://linuxtv.org/patchwork_stats.php
It requires pandas and matplotlib to work. It assumes a database
using MySQL, but can easily changed to Postgres or to any other
DB.
Signed-off-by: Mauro Carvalho Chehab
-
PS.: By purpose, I didn't use Django here. It is a way easier for me to
write SQL commands directly than try to guess how to produce the
same results with Django. Also, I don't expect this to be applied
upstream as-is, as, if we're doing some stats module at patchwork, it
would require a lot more: templates, css changes, customizations, etc.
The goal here is just to have something really simple that would
allow to account the number of patches received/accepted/rejected/etc
and produce graphics in a way that we could later easily add/remove
stuff.
The script takes a 2 years window and includes the current month,
but it should be easy to change it to any other period of time.
The drawback is that this script will require changes if the database
model changes. It was produced against stable 2.1 data model.
Yet, as others may want to provide similar things, I'm providing
the code we use at linuxtv.org (with the DB connection details
sanitized).
+#!/usr/bin/env python
+
+import matplotlib
+matplotlib.use('Agg')
+
+import MySQLdb
+import pandas as pd
+import matplotlib.pyplot as plt
+
+conn = MySQLdb.connect(host="localhost", user="my_patchwork_user",
passwd="my_password", db="patchwork_db_name")
+cursor = conn.cursor()
+
+# Total patches
+
+df = pd.read_sql('select DATE_FORMAT(date, "%Y-%m") AS date , count(*) AS
patches from patchwork_submission WHERE date between
DATE_SUB(DATE_FORMAT(CURRENT_DATE,"%Y-%m-01"),INTERVAL 2 YEAR) and NOW() group
by DATE_FORMAT(date, "%Y-%m") ORDER BY YEAR(date), MONTH(DATE)', con=conn)
+df['date'] = pd.to_datetime(df.date, format='%Y-%m')
+
+fig = plt.figure(figsize=(10,6), facecolor='w', edgecolor='k')
+ax = fig.add_subplot(1,1,1)
+#ax.bar(df.date, df.patches)
+ax.plot_date(df.date, df.patches, 'ob')
+ax.patch.set_facecolor('lightgrey')
+ax.set_ylim(bottom=0)
+fig.autofmt_xdate()
+ax.set_title('Number of patches received by month')
+ax.autoscale_view()
+
+plt.grid()
+plt.savefig('htdocs/static/images/patches_per_date.svg')
+
+# Patches per state
+
+df = pd.read_sql('select DATE_FORMAT(date, "%Y-%m") as date, st.name, count(*)
as patches from patchwork.patchwork_patch AS p, patchwork.patchwork_submission
as s, patchwork_state as st where date between
DATE_SUB(DATE_FORMAT(CURRENT_DATE,"%Y-%m-01"),INTERVAL 2 YEAR) and NOW() and
s.id = p.submission_ptr_id and state_id = st.id group by DATE_FORMAT(date,
"%Y-%m"), state_id', con=conn)
+df['date'] = pd.to_datetime(df.date, format='%Y-%m')
+df.set_index('date', inplace=True)
+
+fig, ax = plt.subplots(figsize=(14,6))
+
+df.groupby(['name'])['patches'].plot(ax=ax, legend=True)
+ax.patch.set_facecolor('lightgrey')
+ax.set_ylim(bottom=0)
+fig.autofmt_xdate()
+ax.set_title('Number of patches per state per month')
+ax.autoscale_view()
+
+plt.grid()
+plt.legend(loc="upper left", bbox_to_anchor=(1.05,1.0))
+plt.subplots_adjust(left=0.1, bottom=0.15, right=0.8)
+plt.savefig('htdocs/static/images/patches_per_state.svg')
Thanks,
Mauro
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
[PATCH v2 4/5] Update api documentation for v1.2
Signed-off-by: Mete Polat
---
In the index.rst (section 'supported versions') we have to specify since which
patchwork version an api version is available. If this patch will be integrated
in a patchwork version other than 2.2, the version number has to be updated
here.
docs/api/rest/index.rst| 50 +-
docs/api/rest/schemas/v1.1.rst |4 +-
docs/api/rest/schemas/v1.2.rst |5 +
docs/api/schemas/generate_schema.py|4 +-
docs/api/schemas/latest/patchwork.yaml |7 +-
docs/api/schemas/patchwork.j2 |7 +
docs/api/schemas/v1.2/patchwork.yaml | 2319
7 files changed, 2370 insertions(+), 26 deletions(-)
create mode 100644 docs/api/rest/schemas/v1.2.rst
create mode 100644 docs/api/schemas/v1.2/patchwork.yaml
diff --git a/docs/api/rest/index.rst b/docs/api/rest/index.rst
index 1a094d7..f6b6380 100644
--- a/docs/api/rest/index.rst
+++ b/docs/api/rest/index.rst
@@ -8,7 +8,7 @@ This guide provides an overview of how one can interact with
the REST API. For
detailed information on type and response format of the various resources
exposed by the API, refer to the web browsable API. This can be found at:
-https://patchwork.example.com/api/1.1/
+https://patchwork.example.com/api/1.2/
where `patchwork.example.com` refers to the URL of your Patchwork instance.
@@ -33,6 +33,12 @@ If all you want is reference guides, skip straight to
:ref:`rest-api-schemas`.
The API version was bumped to v1.1 in Patchwork v2.1. The older v1.0 API is
still supported. For more information, refer to :ref:`rest-api-versions`.
+.. versionchanged:: 2.2
+
+ The API version was bumped to v1.2 in Patchwork v2.2. The older v1.0 and
v1.1
+ APIs are still supported. For more information, refer to
+ :ref:`rest-api-versions`.
+
Getting Started
---
@@ -47,16 +53,16 @@ Patchwork instance hosted at `patchwork.example.com`, run:
.. code-block:: shell
-$ curl -s 'https://patchwork.example.com/api/1.1/' | python -m json.tool
+$ curl -s 'https://patchwork.example.com/api/1.2/' | python -m json.tool
{
-"bundles": "https://patchwork.example.com/api/1.1/bundles/;,
-"covers": "https://patchwork.example.com/api/1.1/covers/;,
-"events": "https://patchwork.example.com/api/1.1/events/;,
-"patches": "https://patchwork.example.com/api/1.1/patches/;,
-"people": "https://patchwork.example.com/api/1.1/people/;,
-"projects": "https://patchwork.example.com/api/1.1/projects/;,
-"series": "https://patchwork.example.com/api/1.1/series/;,
-"users": "https://patchwork.example.com/api/1.1/users/;
+"bundles": "https://patchwork.example.com/api/1.2/bundles/;,
+"covers": "https://patchwork.example.com/api/1.2/covers/;,
+"events": "https://patchwork.example.com/api/1.2/events/;,
+"patches": "https://patchwork.example.com/api/1.2/patches/;,
+"people": "https://patchwork.example.com/api/1.2/people/;,
+"projects": "https://patchwork.example.com/api/1.2/projects/;,
+"series": "https://patchwork.example.com/api/1.2/series/;,
+"users": "https://patchwork.example.com/api/1.2/users/;
}
@@ -69,17 +75,17 @@ well-supported. To repeat the above example using
`requests`:, run
$ python
>>> import json
>>> import requests
->>> r = requests.get('https://patchwork.example.com/api/1.1/')
+>>> r = requests.get('https://patchwork.example.com/api/1.2/')
>>> print(json.dumps(r.json(), indent=2))
{
-"bundles": "https://patchwork.example.com/api/1.1/bundles/;,
-"covers": "https://patchwork.example.com/api/1.1/covers/;,
-"events": "https://patchwork.example.com/api/1.1/events/;,
-"patches": "https://patchwork.example.com/api/1.1/patches/;,
-"people": "https://patchwork.example.com/api/1.1/people/;,
-"projects": "https://patchwork.example.com/api/1.1/projects/;,
-"series": "https://patchwork.example.com/api/1.1/series/;,
-"users": "https://patchwork.example.com/api/1.1/users/;
+"bundles": "https://patchwork.example.com/api/1.2/bundles/;,
+"covers": "https://patchwork.example.com/api/1.2/covers/;,
+"events": "https://patchwork.example.com/api/1.2/events/;,
+"patches": "https://patchwork.example.com/api/1.2/patches/;,
+"people": "https://patchwork.example.com/api/1.2/people/;,
+"projects": "https://patchwork.example.com/api/1.2/projects/;,
+"series": "https://patchwork.example.com/api/1.2/series/;,
+"users": "https://patchwork.example.com/api/1.2/users/;
}
Tools like `curl` and libraries like `requests` can be used to build anything
@@ -98,7 +104,7 @@ Versioning
--
By default, all requests will receive the latest version of the API: currently
-``1.1``:
+``1.2``:
.. code-block:: http
@@ -109,7 +115,7 @@ changes breaking your
[PATCH 4/5] Update api documentation for v1.2
Signed-off-by: Mete Polat
---
In the index.rst (section 'supported versions') we have to specify since which
patchwork version an api version is available. If this patch will be integrated
in a patchwork version other than 2.2, the version number has to be updated
here.
docs/api/rest/index.rst| 50 +-
docs/api/rest/schemas/v1.1.rst |4 +-
docs/api/rest/schemas/v1.2.rst |5 +
docs/api/schemas/generate_schema.py|4 +-
docs/api/schemas/latest/patchwork.yaml |7 +-
docs/api/schemas/patchwork.j2 |7 +
docs/api/schemas/v1.2/patchwork.yaml | 2319
7 files changed, 2370 insertions(+), 26 deletions(-)
create mode 100644 docs/api/rest/schemas/v1.2.rst
create mode 100644 docs/api/schemas/v1.2/patchwork.yaml
diff --git a/docs/api/rest/index.rst b/docs/api/rest/index.rst
index 1a094d7..f6b6380 100644
--- a/docs/api/rest/index.rst
+++ b/docs/api/rest/index.rst
@@ -8,7 +8,7 @@ This guide provides an overview of how one can interact with
the REST API. For
detailed information on type and response format of the various resources
exposed by the API, refer to the web browsable API. This can be found at:
-https://patchwork.example.com/api/1.1/
+https://patchwork.example.com/api/1.2/
where `patchwork.example.com` refers to the URL of your Patchwork instance.
@@ -33,6 +33,12 @@ If all you want is reference guides, skip straight to
:ref:`rest-api-schemas`.
The API version was bumped to v1.1 in Patchwork v2.1. The older v1.0 API is
still supported. For more information, refer to :ref:`rest-api-versions`.
+.. versionchanged:: 2.2
+
+ The API version was bumped to v1.2 in Patchwork v2.2. The older v1.0 and
v1.1
+ APIs are still supported. For more information, refer to
+ :ref:`rest-api-versions`.
+
Getting Started
---
@@ -47,16 +53,16 @@ Patchwork instance hosted at `patchwork.example.com`, run:
.. code-block:: shell
-$ curl -s 'https://patchwork.example.com/api/1.1/' | python -m json.tool
+$ curl -s 'https://patchwork.example.com/api/1.2/' | python -m json.tool
{
-"bundles": "https://patchwork.example.com/api/1.1/bundles/;,
-"covers": "https://patchwork.example.com/api/1.1/covers/;,
-"events": "https://patchwork.example.com/api/1.1/events/;,
-"patches": "https://patchwork.example.com/api/1.1/patches/;,
-"people": "https://patchwork.example.com/api/1.1/people/;,
-"projects": "https://patchwork.example.com/api/1.1/projects/;,
-"series": "https://patchwork.example.com/api/1.1/series/;,
-"users": "https://patchwork.example.com/api/1.1/users/;
+"bundles": "https://patchwork.example.com/api/1.2/bundles/;,
+"covers": "https://patchwork.example.com/api/1.2/covers/;,
+"events": "https://patchwork.example.com/api/1.2/events/;,
+"patches": "https://patchwork.example.com/api/1.2/patches/;,
+"people": "https://patchwork.example.com/api/1.2/people/;,
+"projects": "https://patchwork.example.com/api/1.2/projects/;,
+"series": "https://patchwork.example.com/api/1.2/series/;,
+"users": "https://patchwork.example.com/api/1.2/users/;
}
@@ -69,17 +75,17 @@ well-supported. To repeat the above example using
`requests`:, run
$ python
>>> import json
>>> import requests
->>> r = requests.get('https://patchwork.example.com/api/1.1/')
+>>> r = requests.get('https://patchwork.example.com/api/1.2/')
>>> print(json.dumps(r.json(), indent=2))
{
-"bundles": "https://patchwork.example.com/api/1.1/bundles/;,
-"covers": "https://patchwork.example.com/api/1.1/covers/;,
-"events": "https://patchwork.example.com/api/1.1/events/;,
-"patches": "https://patchwork.example.com/api/1.1/patches/;,
-"people": "https://patchwork.example.com/api/1.1/people/;,
-"projects": "https://patchwork.example.com/api/1.1/projects/;,
-"series": "https://patchwork.example.com/api/1.1/series/;,
-"users": "https://patchwork.example.com/api/1.1/users/;
+"bundles": "https://patchwork.example.com/api/1.2/bundles/;,
+"covers": "https://patchwork.example.com/api/1.2/covers/;,
+"events": "https://patchwork.example.com/api/1.2/events/;,
+"patches": "https://patchwork.example.com/api/1.2/patches/;,
+"people": "https://patchwork.example.com/api/1.2/people/;,
+"projects": "https://patchwork.example.com/api/1.2/projects/;,
+"series": "https://patchwork.example.com/api/1.2/series/;,
+"users": "https://patchwork.example.com/api/1.2/users/;
}
Tools like `curl` and libraries like `requests` can be used to build anything
@@ -98,7 +104,7 @@ Versioning
--
By default, all requests will receive the latest version of the API: currently
-``1.1``:
+``1.2``:
.. code-block:: http
@@ -109,7 +115,7 @@ changes breaking your
Re: Patchwork Registration
Hi Stuart! On 5/6/19 9:47 pm, Stuart Foster wrote: Hi, I have have attempted to register with Patchwork but I have not received a confirmation e-mail. The login page recognises my user name and e-mail but blocks my access. How can this be rectified ? Which Patchwork instance is this? patchwork.ozlabs.org or somewhere else? Andrew -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
[PATCH v2] filters: re-add the possibility of filtering undelegated patches
The filters.py redesign that happened for patchwork 1.1 removed
a functionality that we use a lot: to filter patches that weren't
delegated to anyone.
Also, it is a way harder to find someone to delegate with a free
text input. Use, instead a combo-box just like before.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/patchwork/filters.py b/patchwork/filters.py
index 79aaea437c6e..11d00390145a 100644
--- a/patchwork/filters.py
+++ b/patchwork/filters.py
@@ -385,6 +385,7 @@ class ArchiveFilter(Filter):
class DelegateFilter(Filter):
name = 'Delegate'
param = 'delegate'
+no_delegate_str = 'Nobody'
ANY_DELEGATE = object()
def __init__(self, filters):
@@ -416,6 +417,11 @@ class DelegateFilter(Filter):
if not key:
return
+if key == self.no_delegate_str:
+self.delegate_match = key
+self.applied = True
+return
+
try:
self.delegate = User.objects.get(id=int(key))
except (ValueError, User.DoesNotExist):
@@ -436,6 +442,9 @@ class DelegateFilter(Filter):
if self.delegate:
return {'delegate': self.delegate}
+if self.delegate_match == self.no_delegate_str:
+return {'delegate__username__isnull': True}
+
if self.delegate_match:
return {'delegate__username__icontains': self.delegate_match}
@@ -447,8 +456,33 @@ class DelegateFilter(Filter):
return mark_safe('%s' % (
self.param, self.condition))
-return mark_safe('')
+delegates = User.objects.filter(profile__maintainer_projects__isnull =
False)
+
+str = ''
+
+selected = ''
+if not self.applied:
+selected = 'selected'
+
+str += '--' % selected
+
+selected = ''
+if self.applied and self.delegate is None:
+selected = 'selected'
+
+str += '%s' % (
+selected, self.no_delegate_str, self.no_delegate_str)
+
+for delegate in delegates:
+selected = ''
+if delegate == self.delegate:
+selected = ' selected'
+
+str += '%s' % (selected,
+delegate.id, delegate.username)
+str += ''
+
+return mark_safe(str)
def set_status(self, *args, **kwargs):
if 'delegate' in kwargs:
diff --git a/patchwork/templates/patchwork/partials/filters.html
b/patchwork/templates/patchwork/partials/filters.html
index 41ed2c268e46..e89c4d0f6284 100644
--- a/patchwork/templates/patchwork/partials/filters.html
+++ b/patchwork/templates/patchwork/partials/filters.html
@@ -76,44 +76,6 @@ $(document).ready(function() {
});
}
});
-
-$('#delegate_input').selectize({
-plugins: ['enter_key_submit'],
-maxItems: 1,
-persist: false,
-onInitialize: function() {
-this.on('submit', function() {
-if (!this.items.length)
-this.$input.val(this.lastValue);
-this.$input.closest('form').submit();
-}, this);
-},
-{% if "delegate" in filters.applied_filters %}
-{% with delegate_filter=filters.applied_filters.delegate %}
-options: [
-{
-value: "{{ delegate_filter.key }}",
-text: "{{ delegate_filter.condition }}",
-},
-],
-items: ["{{ delegate_filter.key }}"],
-{% endwith %}
-{% endif %}
-load: function(query, callback) {
-req = $.ajax({
-url: "{% url 'api-delegates' %}",
-data: {q: query, l: 10},
-error: function() {
-callback();
-},
-success: function(res) {
-callback($.map(res, function (obj) {
-return {value: obj.pk, text: obj.name};
-}));
-}
-});
-}
-});
});
diff --git
a/releasenotes/notes/Re-added-delegate-to-nobody-filter-and-use-select-for-delegated-people-04a81a4a914965d8.yaml
b/releasenotes/notes/Re-added-delegate-to-nobody-filter-and-use-select-for-delegated-people-04a81a4a914965d8.yaml
new file mode 100644
index ..eb4246e5600e
--- /dev/null
+++
b/releasenotes/notes/Re-added-delegate-to-nobody-filter-and-use-select-for-delegated-people-04a81a4a914965d8.yaml
@@ -0,0 +1,11 @@
+---
+prelude: >
+In the past, Patchwork used to support filtering patches that weren't
+delegated to anyone. This feature was removed in 2015, as part of a
+patch designed to support deletation to anyone. Yet, the feature didn't
+scale and got removed in 2016. So, re-introduce the old logic, fixing
+a regression.
+fixes:
+ - |
+Fix a regression introduced by changeset
+f439f5414206 ("Add delegate filter autocomplete support")
Thanks,
Mauro
___
Patchwork mailing list
Patchwork v2.1.3 Available
We're pleased to announce the release of Patchwork v2.1.3. This release is part of the "Eolienne" release series: https://github.com/getpatchwork/patchwork/releases/tag/v2.1.3 This release is a PATCH release that focuses on bugfixes. For more details, please see below. Happy patchworking! --- Changes in Patchwork v2.1.2..v2.1.3 --- 12b4a194 Release 2.1.3 b0b7e5da filters: re-add the possibility of filtering undelegated patches 9f242641 parser: Remove duplicity f205495b parser: Include extended header lines in diff 7b141134 parser: Add missing extended header lines b58236e9 Revert "parser: Ensure whitespace is stripped for long headers" 8742e9e3 Post-release version bump ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch stack analysis
Hi Daniel, > > > we (Ralf Ramsauer, Lukas Bulwahn and me) are currently working on > > extending the capabilities of Patchwork by combining it with a tool > > called PaStA [1] (Patch Stack Analysis). PaStA is the outcome of a > > research project [2] by the Technical University of Applied Sciences > > Regensburg. It analyses and compares all mails in a mailing list to > > find related ones (e.g former versions of the patch, see [3]). Ralf > > compared PaStA's results for the Linux kernel mailing list with a > > manually created ground truth and achieved an accuracy of 91%. This > > motivated us to integrate PaStA into Patchwork. > > Cool, always interesting to see what people build on top of Patchwork! > I hope we can nicely integrate that into what is already there. > > One bit of relevant Patchwork history: that there's a long-running fork run by > the freedesktop.org people: patchwork.freedesktop.org, > https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/ . They took a > different approach to series than we did: we focused on patches as the key > 'unit' of patchworking, they focused on series as the key unit. They already > have some support for multiple revisions of a series. I don't know how > they've implemented their feature for detecting multiple revisions, but I'm > guessing it's not based on analysis of (commit message, diff) tuples. There's > an example here: > https://patchwork.freedesktop.org/series/49692/ > Yes, we will certainly have a look at what they implemented and consider incorporating the good ideas they had. > > Showing related patches (beside ones in the current series) allows > > developers to understand the patch's evolution better. We have > > adjusted the patch details view and renamed the series patch links > > from "related" to "series". Our new related row shows the patches > > related to each other by PaStA [3][4]. The relations between the > > patches in the screenshot were made manually and the next steps will > > be to automate this procedure with PaStA. > > I'm really wary about incorporating something with so many dependencies > (and with presumably higher resource usage) into the core of patchwork. > Agree. That is also our main concern: we would like to set this up so that the use of pasta is optional and has little impact, e.g., other than exporting some REST API, on the main application. We also want that patchwork and pasta can be running on two different machines and that there is a clear low coupling interface between them. How to achieve this step-by-step is our current discussion. > I'd want to know a few things: > > - what is the accuracy of the FDO Patchwork approach (which I assume is >100% metadata based)? Does it require that patch sumbitters do >particular things (e.g. use the same cover letter title)? Sometimes >we can train users to be helpful in how they submit things to the >lists in order to have them work properly in more simple systems. > > - one key use case is the Linux kernel, where we have stable trees, and >patches getting picked up for those trees. Sometimes those patches >are identical and sometimes they need backporting. Some care would >need to be taken around this. > >An example would be: > - I send this patch to the mailing list: > http://patchwork.ozlabs.org/patch/1099934/ > - It is merged into mainline > - It is proposed for stable trees. This involves multiple threads of > over 100 emails each, including: > * https://lkml.org/lkml/2019/5/29/1655 > * https://lkml.org/lkml/2019/5/30/361 > * (plus 3 others) > >In this case, the original patch is related to the stable patches, >(despite being sent by someone different), and it is interesting and >useful to know what stable series a patch landed in. However, the >patch is not really related to the entire stable patch _series_, and >if you include all the hundreds of patches in your 'related' view in >[3], you will drown out all the potentially useful signal in a bunch >of noise. > >It does get more complicated than this too, for example when there is >a need to packport a patch for stable. (See >e.g. http://patchwork.ozlabs.org/patch/1109024/ and friends) > I agree. We will need to identify stable patches. We already have multiple good indicators that we will investigate: - date of upstream inclusion, when was the patch finally included in the main repository, i.e., date of the Linus' merge commit for a patch - date of the stable patch email - sender of the stable patch email, i.e., it is usually Greg KH or Sascha Levin in the linux kernel development - is some email CC-ed? - does it contain some specific string in the commit message. All these points are mostly project specific, so we will need to check how to make that configurable so that it fits to all the projects and reaches a good precision and recall. > - what's the resource
Re: [RFC PATCH] docker: Add support for using eatmydata in the database
On 3/5/19 5:33 pm, Russell Currey wrote: When running tox on a VM with presumably pretty busy spinning disks, using eatmydata with the database took running one configuration's test suite from (no exaggeration) 20 minutes down to 60 seconds. It makes a huge difference to test speed, so we should make it easily available for developers. The primary motivation here was to automatically test each patch in a timeframe that isn't insane. Open to ideas on how to organise this, whether we do it for MySQL too (which we probably should), whether the base directory should have these files in it, what to call the Dockerfile, etc. I think it's a good thing to have in the repo, though. Signed-off-by: Russell Currey Reviewed-by: Andrew Donnellan --- docker-compose-eatmydata.yml | 32 +++ tools/docker/Dockerfile.eatmydata | 9 + 2 files changed, 41 insertions(+) create mode 100644 docker-compose-eatmydata.yml create mode 100644 tools/docker/Dockerfile.eatmydata diff --git a/docker-compose-eatmydata.yml b/docker-compose-eatmydata.yml new file mode 100644 index 000..27d1604 --- /dev/null +++ b/docker-compose-eatmydata.yml @@ -0,0 +1,32 @@ +version: "3" +services: + db: +build: + context: . + dockerfile: ./tools/docker/Dockerfile.eatmydata +volumes: + - ./tools/docker/db/postdata:/var/lib/postgresql/data +environment: + - POSTGRES_PASSWORD=password + + web: +build: + context: . + dockerfile: ./tools/docker/Dockerfile + args: +- UID +depends_on: + - db +command: python3 manage.py runserver 0.0.0.0:8000 +volumes: + - .:/home/patchwork/patchwork/ +ports: + - "8000:8000" +environment: + - UID + - PW_TEST_DB_HOST=db + - PW_TEST_DB_PORT=5432 + - PW_TEST_DB_TYPE=postgres + - PW_TEST_DB_USER=postgres + - PW_TEST_DB_PASS=password + - PGPASSWORD=password diff --git a/tools/docker/Dockerfile.eatmydata b/tools/docker/Dockerfile.eatmydata new file mode 100644 index 000..693cbb3 --- /dev/null +++ b/tools/docker/Dockerfile.eatmydata @@ -0,0 +1,9 @@ +FROM postgres:9.6 + +RUN apt-get update \ + && apt-get install -y eatmydata \ + && apt-get autoremove -y \ + && rm -rf /var/lib/apt/lists/* + +ENTRYPOINT [ "/usr/bin/eatmydata", "/usr/local/bin/docker-entrypoint.sh" ] +CMD ["postgres"] -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: sort order lost when updating patches
On Sat, May 14, 2016 at 2:21 PM, Len Brown wrote: > On Wed, May 11, 2016 at 2:36 PM, Bjorn Helgaas wrote: >> On Tue, Apr 5, 2016 at 11:27 AM, Bjorn Helgaas wrote: >>> This is on https://patchwork.ozlabs.org/project/linux-pci/list/. I >>> don't see the Patchwork version anywhere, but it's the new stuff. >>> >>> When I update a patch, e.g., to mark it superceded, the patch sort >>> order seems to revert back to date: >>> >>> - Click on "Submitter" heading to sort by submitter so I can remove >>> superceded patches. >>> - Mark superceded patches, set "Change state:" to "Superceded", click >>> "update". >>> - I'm returned to patches sorted by *date*, not by submitter. >>> >>> This makes it a real pain to mark superceded patches. > > Does it help to mark the superceded patch as "archived"? > > Rafael relies heavily on patchwork, and "archived" > and delegation seem to be the key features he uses. I do. Delegation is a key feature for me. I also use different status flags, but I almost always marked "Superseded" patches as "Archived" too. I haven't tried the new stuff yet, thanks for the heads up! ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
[PATCH 3/6] templates: Add mailing list archive link to patch detail page
Add a link to the mailing list archive link to the patch detail page.
Suggested-by: Takashi Iwai
Signed-off-by: Andrew Donnellan
---
patchwork/templates/patchwork/submission.html | 4
1 file changed, 4 insertions(+)
diff --git a/patchwork/templates/patchwork/submission.html
b/patchwork/templates/patchwork/submission.html
index b1ae5429191d..9cebbbeb89aa 100644
--- a/patchwork/templates/patchwork/submission.html
+++ b/patchwork/templates/patchwork/submission.html
@@ -34,7 +34,11 @@ function toggle_div(link_id, headers_id)
Message ID
+ {% if submission.list_archive_url %}
+ {{ submission.msgid|msgid }} (mailing list archive)
+ {% else %}
{{ submission.msgid|msgid }}
+ {% endif %}
{% if submission.state %}
--
2.20.1
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
[PATCH 2/6] models: Add list archive lookup
Add a list_archive_lookup_prefix field to Project, which will contain the
address of a Message-ID redirector, e.g. "https://lore.kernel.org/r/;.
Add a list_archive_url property to Submission and Comment, to generate an
archive lookup URL based on the Message-ID.
We will use this to display links to mailing list archives.
Suggested-by: Takashi Iwai
Signed-off-by: Andrew Donnellan
---
...0035_project_list_archive_lookup_prefix.py | 20
patchwork/models.py | 23 +++
2 files changed, 43 insertions(+)
create mode 100644
patchwork/migrations/0035_project_list_archive_lookup_prefix.py
diff --git a/patchwork/migrations/0035_project_list_archive_lookup_prefix.py
b/patchwork/migrations/0035_project_list_archive_lookup_prefix.py
new file mode 100644
index ..7d5f94a462a5
--- /dev/null
+++ b/patchwork/migrations/0035_project_list_archive_lookup_prefix.py
@@ -0,0 +1,20 @@
+# -*- coding: utf-8 -*-
+# Generated by Django 1.11.21 on 2019-07-01 12:57
+from __future__ import unicode_literals
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+dependencies = [
+('patchwork', '0034_project_list_archive_url'),
+]
+
+operations = [
+migrations.AddField(
+model_name='project',
+name='list_archive_lookup_prefix',
+field=models.CharField(blank=True, help_text=b"URL prefix for the
list archive's Message-ID redirector. To generate the list archive link for a
patch, the Message-ID is appended to the end of this prefix.", max_length=2000),
+),
+]
diff --git a/patchwork/models.py b/patchwork/models.py
index e43b062b6f89..04d87a459e3a 100644
--- a/patchwork/models.py
+++ b/patchwork/models.py
@@ -78,6 +78,11 @@ class Project(models.Model):
scm_url = models.CharField(max_length=2000, blank=True)
webscm_url = models.CharField(max_length=2000, blank=True)
list_archive_url = models.CharField(max_length=2000, blank=True)
+list_archive_lookup_prefix = models.CharField(
+max_length=2000, blank=True,
+help_text="URL prefix for the list archive's Message-ID redirector. "
+"To generate the list archive link for a patch, the Message-ID is "
+"appended to the end of this prefix.")
# configuration options
@@ -358,6 +363,15 @@ class Submission(FilenameMixin, EmailMixin, models.Model):
name = models.CharField(max_length=255)
+@property
+def list_archive_url(self):
+if not self.project.list_archive_lookup_prefix:
+return None
+if not self.msgid:
+return None
+return self.project.list_archive_lookup_prefix + \
+self.msgid.strip('<>')
+
# patchwork metadata
def is_editable(self, user):
@@ -591,6 +605,15 @@ class Comment(EmailMixin, models.Model):
related_query_name='comment',
on_delete=models.CASCADE)
+@property
+def list_archive_url(self):
+if not self.submission.project.list_archive_lookup_prefix:
+return None
+if not self.msgid:
+return None
+return self.project.list_archive_lookup_prefix + \
+self.msgid.strip('<>')
+
def get_absolute_url(self):
return reverse('comment-redirect', kwargs={'comment_id': self.id})
--
2.20.1
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
[PATCH 6/6] releasenotes: Add release note for new list archive fields
Signed-off-by: Andrew Donnellan --- .../list-archive-urls-604e69cd92c6b943.yaml| 18 ++ 1 file changed, 18 insertions(+) create mode 100644 releasenotes/notes/list-archive-urls-604e69cd92c6b943.yaml diff --git a/releasenotes/notes/list-archive-urls-604e69cd92c6b943.yaml b/releasenotes/notes/list-archive-urls-604e69cd92c6b943.yaml new file mode 100644 index ..261f3726cdba --- /dev/null +++ b/releasenotes/notes/list-archive-urls-604e69cd92c6b943.yaml @@ -0,0 +1,18 @@ +--- +features: + - | +Add a field to Project to store a link to the project's mailing list +archive, and display that on the project info page. + - | +Add a field to Project to store a prefix for a Message-ID redirector +for the project's mailing list archive, and display a link to the email +thread for each patch. +api: + - | +The API version has been updated to v1.2. + - | +Projects now expose the ``list_archive_url`` and +``list_archive_lookup_prefix`` attributes. + - | +Patches, comments and cover letters now expose a ``list_archive_url`` +attribute. -- 2.20.1 ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
[PATCH 4/6] api: Add list archive fields
Add the new list archive fields to the API. As this is a
backwards-compatible change, this requires only a minor version increment
to v1.2.
Signed-off-by: Andrew Donnellan
---
patchwork/api/comment.py | 5 +++--
patchwork/api/cover.py| 6 --
patchwork/api/embedded.py | 14 +++---
patchwork/api/patch.py| 15 ---
patchwork/api/project.py | 7 +--
patchwork/urls.py | 4 ++--
6 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/patchwork/api/comment.py b/patchwork/api/comment.py
index 57b37111c30b..290b9cd3f3ce 100644
--- a/patchwork/api/comment.py
+++ b/patchwork/api/comment.py
@@ -47,11 +47,12 @@ class CommentListSerializer(BaseHyperlinkedModelSerializer):
class Meta:
model = Comment
-fields = ('id', 'web_url', 'msgid', 'date', 'subject', 'submitter',
- 'content', 'headers')
+fields = ('id', 'web_url', 'msgid', 'list_archive_url', 'date',
+ 'subject', 'submitter', 'content', 'headers')
read_only_fields = fields
versioned_fields = {
'1.1': ('web_url', ),
+'1.2': ('list_archive_url',),
}
diff --git a/patchwork/api/cover.py b/patchwork/api/cover.py
index 7a663226ade8..caf9a386efa5 100644
--- a/patchwork/api/cover.py
+++ b/patchwork/api/cover.py
@@ -50,11 +50,13 @@ class
CoverLetterListSerializer(BaseHyperlinkedModelSerializer):
class Meta:
model = CoverLetter
-fields = ('id', 'url', 'web_url', 'project', 'msgid', 'date', 'name',
- 'submitter', 'mbox', 'series', 'comments')
+fields = ('id', 'url', 'web_url', 'project', 'msgid',
+ 'list_archive_url', 'date', 'name', 'submitter', 'mbox',
+ 'series', 'comments')
read_only_fields = fields
versioned_fields = {
'1.1': ('web_url', 'mbox', 'comments'),
+'1.2': ('list_archive_url',),
}
extra_kwargs = {
'url': {'view_name': 'api-cover-detail'},
diff --git a/patchwork/api/embedded.py b/patchwork/api/embedded.py
index 60fb9a4e9701..3a5227b33df3 100644
--- a/patchwork/api/embedded.py
+++ b/patchwork/api/embedded.py
@@ -108,10 +108,12 @@ class CoverLetterSerializer(SerializedRelatedField):
class Meta:
model = models.CoverLetter
-fields = ('id', 'url', 'web_url', 'msgid', 'date', 'name', 'mbox')
+fields = ('id', 'url', 'web_url', 'msgid', 'list_archive_url',
+ 'date', 'name', 'mbox')
read_only_fields = fields
versioned_fields = {
'1.1': ('web_url', 'mbox', ),
+'1.2': ('list_archive_url',),
}
extra_kwargs = {
'url': {'view_name': 'api-cover-detail'},
@@ -124,10 +126,12 @@ class PatchSerializer(SerializedRelatedField):
class Meta:
model = models.Patch
-fields = ('id', 'url', 'web_url', 'msgid', 'date', 'name', 'mbox')
+fields = ('id', 'url', 'web_url', 'msgid', 'list_archive_url',
+ 'date', 'name', 'mbox')
read_only_fields = fields
versioned_fields = {
'1.1': ('web_url', ),
+'1.2': ('list_archive_url',),
}
extra_kwargs = {
'url': {'view_name': 'api-patch-detail'},
@@ -158,11 +162,15 @@ class ProjectSerializer(SerializedRelatedField):
class Meta:
model = models.Project
fields = ('id', 'url', 'name', 'link_name', 'list_id',
- 'list_email', 'web_url', 'scm_url', 'webscm_url')
+ 'list_email', 'web_url', 'scm_url', 'webscm_url',
+ 'list_archive_url', 'list_archive_lookup_prefix')
read_only_fields = fields
extra_kwargs = {
'url': {'view_name': 'api-project-detail'},
}
+versioned_fields = {
+'1.2': ('list_archive_url', 'list_archive_lookup_prefix'),
+}
class SeriesSerializer(SerializedRelatedField):
diff --git a/patchwork/api/patch.py b/patchwork/api/patch.py
index 05f6cea84c45..c9360308a56a 100644
--- a/patchwork/api/patch.py
+++ b/patchwork/api/patch.py
@@ -121,15 +121,16 @@ class PatchListSerializer(BaseHyperlinkedModelSerializer):
class Meta:
model = Patch
-fields = ('id', 'url', 'web_url', 'project', 'msgid', 'date', 'name',
- 'commit_ref', 'pull_url', 'state', 'archived', 'hash',
- 'submitter', 'delegate', 'mbox', 'series', 'comments',
- 'check', 'checks', 'tags')
-read_only_fields = ('web_url', 'project', 'msgid', 'date', 'name',
-'hash', 'submitter', 'mbox', 'series', 'comments',
-'check', 'checks', 'tags')
+fields = ('id', 'url', 'web_url', 'project', 'msgid',
+
[PATCH 1/6] models, templates: Add project list archive URL field
Add a field to link to a project's mailing list archive, and display it on
the project info page.
Signed-off-by: Andrew Donnellan
---
.../0034_project_list_archive_url.py | 20 +++
patchwork/models.py | 1 +
patchwork/templates/patchwork/project.html| 6 ++
3 files changed, 27 insertions(+)
create mode 100644 patchwork/migrations/0034_project_list_archive_url.py
diff --git a/patchwork/migrations/0034_project_list_archive_url.py
b/patchwork/migrations/0034_project_list_archive_url.py
new file mode 100644
index ..70d1b2bf8542
--- /dev/null
+++ b/patchwork/migrations/0034_project_list_archive_url.py
@@ -0,0 +1,20 @@
+# -*- coding: utf-8 -*-
+# Generated by Django 1.11.21 on 2019-07-01 12:30
+from __future__ import unicode_literals
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+dependencies = [
+('patchwork', '0033_remove_patch_series_model'),
+]
+
+operations = [
+migrations.AddField(
+model_name='project',
+name='list_archive_url',
+field=models.CharField(blank=True, max_length=2000),
+),
+]
diff --git a/patchwork/models.py b/patchwork/models.py
index a7eee4dbad9a..e43b062b6f89 100644
--- a/patchwork/models.py
+++ b/patchwork/models.py
@@ -77,6 +77,7 @@ class Project(models.Model):
web_url = models.CharField(max_length=2000, blank=True)
scm_url = models.CharField(max_length=2000, blank=True)
webscm_url = models.CharField(max_length=2000, blank=True)
+list_archive_url = models.CharField(max_length=2000, blank=True)
# configuration options
diff --git a/patchwork/templates/patchwork/project.html
b/patchwork/templates/patchwork/project.html
index 99e36ff79d6a..bd9d20e263d8 100644
--- a/patchwork/templates/patchwork/project.html
+++ b/patchwork/templates/patchwork/project.html
@@ -15,6 +15,12 @@
List address
{{project.listemail}}
+{% if project.list_archive_url %}
+
+ List archive
+ {{ project.list_archive_url
}}
+
+{% endif %}
Maintainer{{maintainers|length|pluralize}}
--
2.20.1
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
Re: OpenAPI schema
On 7/8/19 7:41 pm, Stephen Finucane wrote: On Wed, 2019-08-07 at 17:10 +1000, Andrew Donnellan wrote: Currently working on some patches that add some extra fields to the API. Updating the OpenAPI schema, especially with the jinja2 templating that we use for versioning, is difficult, especially for those of us with no background in the OpenAPI format. patchwork.j2 is >2300 lines long, which is more than 2x the LOC in the api directory as measured by sloccount. I can help with this. Just let me know what you'd like to add. If you wanted to do it yourself, I'd personally modify the generated v1.2 API using one of the many online schema editors (like https://editor.swagger.io/) and then feed the changes back into the template when you're done. I got there in the end! Does anyone even use the OpenAPI schema for anything? We use it for two things: API documentation and validation (i.e. tests). The API documentation was my initial goal but the validation part of things helped me uncover quite a few bugs in the API and (I imagine) will help prevent more in the future. It was also a chance to play around with OpenAPI, which is nice. I'd like to keep it around, even if it means I have to make any changes necessary. Yes, I realised it was being used for validation after the number of fixes I had to make to get the tests passing :) I note that DRF apparently has some native support for OpenAPI schema generation (https://www.django-rest-framework.org/api-guide/schemas/) - can we use that? Perhaps with a custom schema generator to handle API versioning. I checked this out (and submitted a few patches to correct some of the many bugs in earlier versions of it). Unfortunately, the schema it generates is far too lossy to be useful, and it does particularly poorly with things that are autogenerated or more freeform fields/filters. I also looked through a couple of Django extensions but they suffered the same issue. As nice as it would have been to auto- generate this stuff, it just wasn't an issue, sadly :( That's unfortunate. -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: [PATCH] models: Add commit_url_format to Project
Andrew Donnellan writes: > On 7/8/19 9:22 am, Andrew Donnellan wrote: >> On 6/8/19 10:20 pm, Michael Ellerman wrote: >>> Add a new field to Project, commit_url_format, which specifies a >>> format string that can be used to generate a link to a particular >>> commit for a project. >>> >>> This is used in the display of a patch, to render the patch's commit >>> as a clickable link back to the commit on the SCM website. >>> >>> Signed-off-by: Michael Ellerman >> >> Argh, I've actually got a series of my own pending to do exactly this, >> just had to tidy up the documentation before sending it :) >> >> I'll take a look at this and compare later today. > > I correct myself, I have patches to add mailing list archive links, > which is slightly different! Phew! > My series includes a minor bump to the API versioning, which per > docs/development/releasing.rst is our policy when adding new fields. > I'll tidy that up and send it and perhaps you can rebase your API > changes on top of that? Sure, just let me know. cheers ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: OpenAPI schema
On Wed, 2019-08-07 at 17:10 +1000, Andrew Donnellan wrote: > Currently working on some patches that add some extra fields to the API. > > Updating the OpenAPI schema, especially with the jinja2 templating that > we use for versioning, is difficult, especially for those of us with no > background in the OpenAPI format. patchwork.j2 is >2300 lines long, > which is more than 2x the LOC in the api directory as measured by sloccount. I can help with this. Just let me know what you'd like to add. If you wanted to do it yourself, I'd personally modify the generated v1.2 API using one of the many online schema editors (like https://editor.swagger.io/) and then feed the changes back into the template when you're done. > Does anyone even use the OpenAPI schema for anything? We use it for two things: API documentation and validation (i.e. tests). The API documentation was my initial goal but the validation part of things helped me uncover quite a few bugs in the API and (I imagine) will help prevent more in the future. It was also a chance to play around with OpenAPI, which is nice. I'd like to keep it around, even if it means I have to make any changes necessary. > I note that DRF apparently has some native support for OpenAPI schema > generation (https://www.django-rest-framework.org/api-guide/schemas/) - > can we use that? Perhaps with a custom schema generator to handle API > versioning. I checked this out (and submitted a few patches to correct some of the many bugs in earlier versions of it). Unfortunately, the schema it generates is far too lossy to be useful, and it does particularly poorly with things that are autogenerated or more freeform fields/filters. I also looked through a couple of Django extensions but they suffered the same issue. As nice as it would have been to auto- generate this stuff, it just wasn't an issue, sadly :( Stephen ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
OpenAPI schema
Currently working on some patches that add some extra fields to the API. Updating the OpenAPI schema, especially with the jinja2 templating that we use for versioning, is difficult, especially for those of us with no background in the OpenAPI format. patchwork.j2 is >2300 lines long, which is more than 2x the LOC in the api directory as measured by sloccount. Does anyone even use the OpenAPI schema for anything? I note that DRF apparently has some native support for OpenAPI schema generation (https://www.django-rest-framework.org/api-guide/schemas/) - can we use that? Perhaps with a custom schema generator to handle API versioning. -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
