Re: [PATCH] docs: Document the various management commands available

[Thomas Monjalon]

30/05/2017 17:15, Stephen Finucane:
> As requested.
> 
> Signed-off-by: Stephen Finucane <step...@that.guru>
> Reported-by: Thomas Monjalon <thomas.monja...@6wind.com>
> Closes-bug: #77

Thanks Stephen

> +   ./manage.py cron
> +
> +Run periodic Patchwork functions: send notifications and expire unused users.
> +
> +This is required to ensure notifications emails are actually sent to users 
> that
> +request them. For more information on integration of this script, refer to 
> the
> +:ref:`deployment installation guide `.

And "expiring unused users" allows to clean up the fake users from spambots.

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH] Improve documentation of delegation rules

[Thomas Monjalon]

2017-02-07 21:45, Stephen Finucane:
> Per feedback from FOSDEM, this is still confusing some people. Clarify
> things.
> 
> You might think we could just strip of the offending prefixes but that
> might not always be the thing to do. Other VCSs don't include these
> prefixes and both 'a' and 'b' are valid folder names. The risk of false
> positives might be small, but it's enough to discourage us from doing
> this.
> 
> Signed-off-by: Stephen Finucane <step...@that.guru>
> Cc: Thomas Monjalon <thomas.monja...@6wind.com>

OK, that's really clear now. Thank you!
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH] pwclient: Fix encoding problems

[Thomas Monjalon]

2016-12-15 17:56, Robin Jarry:
> All data returned by the xmlrpc object is unicode decoded with 'utf-8' (on
> python 3, unicode == str). Add from __future__ import unicode_literals
> to make sure that everything is unicode and avoid surprises.
> 
> On python 2, printing unicode to stdout causes it to be encoded to str
> (byte string) with the 'ascii' codec:
> 
>   >>> print some_unicode_string
>   ...
>   UnicodeEncodeError: 'ascii' codec can't encode character u'\u0142'
>   in position 468: ordinal not in range(128)
> 
> Work around ths by avoiding any explicit call to unicode() and by
> replacing sys.stdout and sys.stderr by unicode-aware file objects (as
> returned by io.open()).
> 
> Guess the encoding of stdout and stderr by looking at (in that order):
> sys.stdout.encoding, locale.getpreferredencoding(), the PYTHONIOENCODING
> environment variable. If no encoding is defined, assume 'utf-8' as
> output encoding.
> 
> Signed-off-by: Robin Jarry <robin.ja...@6wind.com>

It works with Python 2 and 3 on my machine.
Thanks Robin.

Tested-by: Thomas Monjalon <thomas.monja...@6wind.com>

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH v2 3/3] pwclient: Fix Python 3 encoding of received strings

[Thomas Monjalon]

2016-12-13 11:37, Thomas Monjalon:
> The conversion encode("utf-8") makes a byte stream which is
> poorly printed with Python 3.
[...]
>  for patch_id in non_empty(h, patch_ids):
>  s = rpc.patch_get_mbox(patch_id)
>  if len(s) > 0:
> -print(unicode(s).encode("utf-8"))
> +print(unicode(s))

I really do not understand these conversions.
I've just found a bug with this patch (sorry it is already applied).

When running the view command with python2 from a shell script there
is an error because of a non-ascii character:

  File "pwclient", line 768, in main
print(unicode(s))
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0142'
in position 468: ordinal not in range(128)

This error does not happen with python3.

Shell script to reproduce the error with a DPDK patch:

#! /bin/sh -e
python2 pwclient view 17892

.pwclientrc:
[options]   
 
default=dpdk
[dpdk]
url= http://dpdk.org/dev/patchwork/xmlrpc/

What is the magical invocation to make it work with Python 2 and 3?
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH v2 0/3] pwclient: python 3 and proxy support

[Thomas Monjalon]

These patches should close the issues #47 and #59 by adding proxy support
and fixing authentication (for write operations) with Python 3.
Note: I have not tested with https.

The last patch tries to fix the strings and patch files with Python 3.
I am not sure to understand all these encoding stuff but it works for me.

These patches were tested with patchwork 1.1 and ported to the master branch.
If they are accepted, a backport on 1.1 would be greatly appreciated. Thanks

Thomas Monjalon (3):
  pwclient: Rework HTTP authentication
  pwclient: Support proxy configuration
  pwclient: Fix Python 3 encoding of received strings

changes in v2:
- do not test empty strings against None: s/ is not None//
- add Reviewed-by: Stephen Finucane <step...@that.guru>

 patchwork/bin/pwclient | 77 --
 1 file changed, 44 insertions(+), 33 deletions(-)

-- 
2.7.0

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH v2 2/3] pwclient: Support proxy configuration

[Thomas Monjalon]

The environment variables http_proxy and https_proxy can be used
to configure the HTTP transport.

The TCP connection is made with the proxy host, whereas the original host
is maintained in the HTTP POST URI via "handler" in "send_request".

The send_request() method of xmlrpclib has a different signature
and behaviour in Python 2 and 3.

Fixes #47

Signed-off-by: Thomas Monjalon <thomas.monja...@6wind.com>
Reviewed-by: Stephen Finucane <step...@that.guru>
---
 patchwork/bin/pwclient | 24 
 1 file changed, 24 insertions(+)

diff --git a/patchwork/bin/pwclient b/patchwork/bin/pwclient
index 633ffc2..660ed76 100755
--- a/patchwork/bin/pwclient
+++ b/patchwork/bin/pwclient
@@ -107,12 +107,24 @@ class Transport(xmlrpclib.SafeTransport):
 def __init__(self, url):
 xmlrpclib.SafeTransport.__init__(self)
 self.credentials = None
+self.host = None
+self.proxy = None
+self.scheme = url.split('://', 1)[0]
 self.https = url.startswith('https')
+if self.https:
+self.proxy = os.environ.get('https_proxy')
+else:
+self.proxy = os.environ.get('http_proxy')
+if self.proxy:
+self.https = self.proxy.startswith('https')
 
 def set_credentials(self, username=None, password=None):
 self.credentials = '%s:%s' % (username, password)
 
 def make_connection(self, host):
+self.host = host
+if self.proxy:
+host = self.proxy.split('://', 1)[-1]
 if self.credentials:
 host = '@'.join([self.credentials, host])
 if self.https:
@@ -120,6 +132,18 @@ class Transport(xmlrpclib.SafeTransport):
 else:
 return xmlrpclib.Transport.make_connection(self, host)
 
+if sys.version_info[0] == 2:
+
+def send_request(self, connection, handler, request_body):
+handler = '%s://%s%s' % (self.scheme, self.host, handler)
+xmlrpclib.Transport.send_request(self, connection, handler, 
request_body)
+
+else: # Python 3
+
+def send_request(self, host, handler, request_body, debug):
+handler = '%s://%s%s' % (self.scheme, host, handler)
+return xmlrpclib.Transport.send_request(self, host, handler, 
request_body, debug)
+
 
 def project_id_by_name(rpc, linkname):
 """Given a project short name, look up the Project ID."""
-- 
2.7.0

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH v2 3/3] pwclient: Fix Python 3 encoding of received strings

[Thomas Monjalon]

The conversion encode("utf-8") makes a byte stream which is
poorly printed with Python 3.
However this encoding is required for Popen.communicate() but must be
done after str.join() which applies to a real string.

Signed-off-by: Thomas Monjalon <thomas.monja...@6wind.com>
Reviewed-by: Stephen Finucane <step...@that.guru>
---
 patchwork/bin/pwclient | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/patchwork/bin/pwclient b/patchwork/bin/pwclient
index 660ed76..7ea8878 100755
--- a/patchwork/bin/pwclient
+++ b/patchwork/bin/pwclient
@@ -269,7 +269,7 @@ def action_check_info(rpc, check_id):
 print(s)
 print('-' * len(s))
 for key, value in sorted(check.items()):
-print("- %- 14s: %s" % (key, unicode(value).encode("utf-8")))
+print("- %- 14s: %s" % (key, unicode(value)))
 
 
 def action_check_create(rpc, patch_id, context, state, url, description):
@@ -293,7 +293,7 @@ def action_info(rpc, patch_id):
 print(s)
 print('-' * len(s))
 for key, value in sorted(patch.items()):
-print("- %- 14s: %s" % (key, unicode(value).encode("utf-8")))
+print("- %- 14s: %s" % (key, unicode(value)))
 
 
 def action_get(rpc, patch_id):
@@ -311,7 +311,7 @@ def action_get(rpc, patch_id):
 i += 1
 
 with open(fname, 'w') as f:
-f.write(unicode(s).encode("utf-8"))
+f.write(unicode(s))
 print('Saved patch to %s' % fname)
 
 
@@ -748,15 +748,15 @@ def main():
 for patch_id in non_empty(h, patch_ids):
 s = rpc.patch_get_mbox(patch_id)
 if len(s) > 0:
-i.append(unicode(s).encode("utf-8"))
+i.append(unicode(s))
 if len(i) > 0:
-pager.communicate(input="\n".join(i))
+pager.communicate(input="\n".join(i).encode("utf-8"))
 pager.stdin.close()
 else:
 for patch_id in non_empty(h, patch_ids):
 s = rpc.patch_get_mbox(patch_id)
 if len(s) > 0:
-print(unicode(s).encode("utf-8"))
+print(unicode(s))
 
 elif action == 'info':
 for patch_id in non_empty(h, patch_ids):
-- 
2.7.0

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH] views: Add List-Id to mbox

[Thomas Monjalon]

2016-12-12 11:12, Stephen Finucane:
> On Sun, 2016-12-11 at 12:39 +0100, Thomas Monjalon wrote:
> > The List-Id header is retrieved from the Project object.
> > 
> > Fixes #53
> > 
> > Signed-off-by: Thomas Monjalon <thomas.monja...@6wind.com>
> 
> Thanks, Thomas. Before merging, would it be possible to get a test to
> make sure this doesn't regress? A quick look suggests 'test_mboxviews'
> is the place to do this.

I've just seen you did already it:
https://patchwork.ozlabs.org/patch/696885/

Why not merging your patch instead?

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH] views: Add List-Id to mbox

[Thomas Monjalon]

The List-Id header is retrieved from the Project object.

Fixes #53

Signed-off-by: Thomas Monjalon <thomas.monja...@6wind.com>
---
 patchwork/views/__init__.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/patchwork/views/__init__.py b/patchwork/views/__init__.py
index 58fb29f..db11e03 100644
--- a/patchwork/views/__init__.py
+++ b/patchwork/views/__init__.py
@@ -389,6 +389,7 @@ def patch_to_mbox(patch):
 if patch.delegate:
 mail['X-Patchwork-Delegate'] = str(patch.delegate.email)
 mail['Message-Id'] = patch.msgid
+mail['List-Id'] = patch.project.listid
 mail.set_unixfrom('From patchwork ' + patch.date.ctime())
 
 copied_headers = ['To', 'Cc', 'Date']
-- 
2.7.0

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH 2/3] pwclient: Support proxy configuration

[Thomas Monjalon]

The environment variables http_proxy and https_proxy can be used
to configure the HTTP transport.

The TCP connection is made with the proxy host, whereas the original host
is maintained in the HTTP POST URI via "handler" in "send_request".

The send_request() method of xmlrpclib has a different signature
and behaviour in Python 2 and 3.

Fixes #47

Signed-off-by: Thomas Monjalon <thomas.monja...@6wind.com>
---
 patchwork/bin/pwclient | 24 
 1 file changed, 24 insertions(+)

diff --git a/patchwork/bin/pwclient b/patchwork/bin/pwclient
index 9ec8898..42a7fd0 100755
--- a/patchwork/bin/pwclient
+++ b/patchwork/bin/pwclient
@@ -107,12 +107,24 @@ class Transport(xmlrpclib.SafeTransport):
 def __init__(self, url):
 xmlrpclib.SafeTransport.__init__(self)
 self.credentials = None
+self.host = None
+self.proxy = None
+self.scheme = url.split('://', 1)[0]
 self.https = url.startswith('https')
+if self.https:
+self.proxy = os.environ.get('https_proxy')
+else:
+self.proxy = os.environ.get('http_proxy')
+if self.proxy is not None:
+self.https = self.proxy.startswith('https')
 
 def set_credentials(self, username=None, password=None):
 self.credentials = '%s:%s' % (username, password)
 
 def make_connection(self, host):
+self.host = host
+if self.proxy is not None:
+host = self.proxy.split('://', 1)[-1]
 if self.credentials is not None:
 host = '@'.join([self.credentials, host])
 if self.https:
@@ -120,6 +132,18 @@ class Transport(xmlrpclib.SafeTransport):
 else:
 return xmlrpclib.Transport.make_connection(self, host)
 
+if sys.version_info[0] == 2:
+
+def send_request(self, connection, handler, request_body):
+handler = '%s://%s%s' % (self.scheme, self.host, handler)
+xmlrpclib.Transport.send_request(self, connection, handler, 
request_body)
+
+else: # Python 3
+
+def send_request(self, host, handler, request_body, debug):
+handler = '%s://%s%s' % (self.scheme, host, handler)
+return xmlrpclib.Transport.send_request(self, host, handler, 
request_body, debug)
+
 
 def project_id_by_name(rpc, linkname):
 """Given a project short name, look up the Project ID."""
-- 
2.7.0

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH 3/3] pwclient: Fix Python 3 encoding of received strings

[Thomas Monjalon]

The conversion encode("utf-8") makes a byte stream which is
poorly printed with Python 3.
However this encoding is required for Popen.communicate() but must be
done after str.join() which applies to a real string.

Signed-off-by: Thomas Monjalon <thomas.monja...@6wind.com>
---
 patchwork/bin/pwclient | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/patchwork/bin/pwclient b/patchwork/bin/pwclient
index 42a7fd0..5a9e93c 100755
--- a/patchwork/bin/pwclient
+++ b/patchwork/bin/pwclient
@@ -269,7 +269,7 @@ def action_check_info(rpc, check_id):
 print(s)
 print('-' * len(s))
 for key, value in sorted(check.items()):
-print("- %- 14s: %s" % (key, unicode(value).encode("utf-8")))
+print("- %- 14s: %s" % (key, unicode(value)))
 
 
 def action_check_create(rpc, patch_id, context, state, url, description):
@@ -293,7 +293,7 @@ def action_info(rpc, patch_id):
 print(s)
 print('-' * len(s))
 for key, value in sorted(patch.items()):
-print("- %- 14s: %s" % (key, unicode(value).encode("utf-8")))
+print("- %- 14s: %s" % (key, unicode(value)))
 
 
 def action_get(rpc, patch_id):
@@ -311,7 +311,7 @@ def action_get(rpc, patch_id):
 i += 1
 
 with open(fname, 'w') as f:
-f.write(unicode(s).encode("utf-8"))
+f.write(unicode(s))
 print('Saved patch to %s' % fname)
 
 
@@ -748,15 +748,15 @@ def main():
 for patch_id in non_empty(h, patch_ids):
 s = rpc.patch_get_mbox(patch_id)
 if len(s) > 0:
-i.append(unicode(s).encode("utf-8"))
+i.append(unicode(s))
 if len(i) > 0:
-pager.communicate(input="\n".join(i))
+pager.communicate(input="\n".join(i).encode("utf-8"))
 pager.stdin.close()
 else:
 for patch_id in non_empty(h, patch_ids):
 s = rpc.patch_get_mbox(patch_id)
 if len(s) > 0:
-print(unicode(s).encode("utf-8"))
+print(unicode(s))
 
 elif action == 'info':
 for patch_id in non_empty(h, patch_ids):
-- 
2.7.0

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH 0/3] pwclient: python 3 and proxy support

[Thomas Monjalon]

These patches should close the issues #47 and #59 by adding proxy support
and fixing authentication (for write operations) with Python 3.
Note: I have not tested with https.

The last patch tries to fix the strings and patch files with Python 3.
I am not sure to understand all these encoding stuff but it works for me.

These patches were tested with patchwork 1.1 and ported to the master branch.
If they are accepted, a backport on 1.1 would be greatly appreciated. Thanks

Thomas Monjalon (3):
  pwclient: Rework HTTP authentication
  pwclient: Support proxy configuration
  pwclient: Fix Python 3 encoding of received strings

 patchwork/bin/pwclient | 77 --
 1 file changed, 44 insertions(+), 33 deletions(-)

-- 
2.7.0

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH 5/5] docs: Add delegation guide

[Thomas Monjalon]

Hi,

2016-10-11 19:01, Stephen Finucane:
> We do autodelegation - let's tell people all about it.

I am reading this documentation at
https://patchwork.readthedocs.io/en/latest/usage/delegation/
I have two questions about this feature.

Is the path starting with a slash?

What happens if a file does not match any rule?
What happens if two files match two rules leading to the same user?
What happens if two files match two rules leading to different users?

Thanks
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH v6 1/2] parsemail: Convert to a management command

[Thomas Monjalon]

Hi,

2016-09-20 00:08, Stephen Finucane:
> On 20 Sep 01:22, Daniel Axtens wrote:
> > So, umm, I went ahead and had a crack at this.
> > 
> > It turns out this is hideously difficult to get right. But this plus my
> > other patch to fix Thomas' problem should have things working on Py2 and
> > Py3 with this series.

Thanks for taking care.

[...]
> I don't have the offending patch on hand, but isn't the issue with the
> headers. If so, would something like the below do (I haven't tested
> it - there could be typos).
[...]

Please would it be possible to fix this bug in the stable branch also?
Thanks a lot
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

encoding error when parsing email

[Thomas Monjalon]

Hi,

Sometimes we receive some patches with a strange character in
a header "Received:" so the patch is not parsed in patchwork.
I have not yet investigated where the script is failing,
but I just want to ask first if there is a work in progress
about this issue?
And could it be fixed by removing "Received:" lines from the email?

Thanks
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

filter not delegated patches

[Thomas Monjalon]

Hi,

I was using a very convenient feature in the old patchwork that
I cannot find in the version 1.1:

In the filter box, the delegate field can be filled on completion only.
It would be more convenient to list the possible values in the drop-down
(i.e. people who had some patches delegated to them) but it is not really
my issue.
More importantly, I would like to be able to find the patches which are
not delegated at all. Is there a way to do this please?

I guess it is related to the call $('#delegate_input').selectize() in
patchwork/templates/patchwork/filters.html and in patchwork/filters.py?
Is allowEmptyOption of selectize to be considered?
There is also a bug entry for this option:
https://github.com/selectize/selectize.js/issues/739

Thanks
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: manual delegation to any user as an option

[Thomas Monjalon]

2016-09-09 20:39, Stephen Finucane:
> On 08 Sep 17:41, Thomas Monjalon wrote:
> > Hi,
> > 
> > I would like to talk about the following commit:
> > Allow assigning of any user as delegate
> > https://github.com/getpatchwork/patchwork/commit/e0fd7cd91a5
> > 
> > It can result to a very large list of people in the drop down.
> > It is cool that we can use a kind of autocomplete to find someone,
> > but it would be better if it was alphabetically sorted.
> 
> Yeah, it isn't ideal as things stand. AFAIK, the ozlabs instance has
> that particular patch reverted.

It is also reverted on dpdk.org.

> However, I'm hoping to fix it by
> reworking that page slightly before 2.0 is released. There's a bug
> marked upstream [1], and I hope to switch to an AJAX-based search box.
> 
> > I also wonder if people really want to appear publicly in this list.
> > That's why I think it would even better to have an opt-in per-user.
> 
> I could see reasons for wanting this, but having a "don't index me"
> option isn't something I could see being viable/useful. This
> information is already available, either through screenscraping
> Patchwork or parsing mbox files from an archive.

I was talking about patchwork users who do not participate on the
mailing list and do not want to appear anywhere.

> > Finally some projects may choose to make things simpler and classify
> > patches only automatically or to maintainers (the old behaviour).
> > For those projects, a global option to enable/disable user delegation
> > would be great.
> 
> Not a bad idea. I'll consider that in the above work.

Thanks Stephen
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH 0/4] small UI improvements

[Thomas Monjalon]

These patches have been tested on patchwork 1.1.1 (with few patches
from master) and the result can be seen at:
http://dpdk.org/dev/patchwork
They have been rebased on master without more test.

There is no truth about UI so I would understand easily if those patches
were rejected, especially the third one "Shrink vertical space".
Don't worry, it's just a UI proposal ;)

Thomas Monjalon (4):
  ui: Align patch row with checkbox vertically
  ui: Align patch form with above metadata
  ui: Shrink vertical space
  ui: Reduce size of quoted comments

 htdocs/css/style.css  | 15 +--
 patchwork/templates/patchwork/list.html   |  2 --
 patchwork/templates/patchwork/submission.html |  4 +---
 3 files changed, 10 insertions(+), 11 deletions(-)

-- 
2.7.0

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH 3/4] ui: Shrink vertical space

[Thomas Monjalon]

Reduce some vertical padding/margin and remove some useless titles
in list.html and patch.html.

Signed-off-by: Thomas Monjalon <thomas.monja...@6wind.com>
---
 htdocs/css/style.css  | 10 +-
 patchwork/templates/patchwork/list.html   |  2 --
 patchwork/templates/patchwork/submission.html |  4 +---
 3 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/htdocs/css/style.css b/htdocs/css/style.css
index a84f03c..0bf4b43 100644
--- a/htdocs/css/style.css
+++ b/htdocs/css/style.css
@@ -91,8 +91,8 @@ dl dt {
 .filters {
 border: 1px solid #cc;
 border-radius: 4px;
-padding: 10px 20px;
-margin-bottom: 20px;
+padding: 5px 20px;
+margin: 15px 0;
 }
 
 a.filter-action {
@@ -119,7 +119,7 @@ div.filters {
 }
 
 div.patchforms {
-   margin-top: 2em;
+   margin-top: 1em;
 }
 
 /* list order manipulation */
@@ -145,7 +145,7 @@ input#reorder-change {
 .paginator {
text-align: right;
clear: both;
-margin: 8px 0 20px;
+margin: 8px 0 15px;
 }
 
 .paginator .prev-na,
@@ -184,7 +184,7 @@ table.patchmeta th {
 
 table.patchmeta tr th, table.patchmeta tr td {
text-align: left;
-   padding: 3px 10px 3px 10px;
+   padding: 1px 10px;
vertical-align: middle;
 }
 
diff --git a/patchwork/templates/patchwork/list.html 
b/patchwork/templates/patchwork/list.html
index 9fec773..180c560 100644
--- a/patchwork/templates/patchwork/list.html
+++ b/patchwork/templates/patchwork/list.html
@@ -8,8 +8,6 @@
 
 {% block body %}
 
-Patches
-
 {% if errors %}
 The following error{{ errors|length|pluralize:" was,s were" }} encountered
 while updating patches:
diff --git a/patchwork/templates/patchwork/submission.html 
b/patchwork/templates/patchwork/submission.html
index 088cceb..f22c1d0 100644
--- a/patchwork/templates/patchwork/submission.html
+++ b/patchwork/templates/patchwork/submission.html
@@ -28,12 +28,10 @@ function toggle_headers(link_id, headers_id)
 
 
 {{ submission.name }}
-
+
  Submitted by {{ submission.submitter|personify:project }} on {{ 
submission.date }}
 
 
-Details
-
 
  
   Message ID
-- 
2.7.0

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH 4/4] ui: Reduce size of quoted comments

[Thomas Monjalon]

The quoted comments are already written in the previous comment.
Being smaller (in addition to be green) makes them easier to visually
skip.

Signed-off-by: Thomas Monjalon <thomas.monja...@6wind.com>
---
 htdocs/css/style.css | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/htdocs/css/style.css b/htdocs/css/style.css
index 0bf4b43..33822d1 100644
--- a/htdocs/css/style.css
+++ b/htdocs/css/style.css
@@ -266,6 +266,8 @@ table.patchmeta tr th, table.patchmeta tr td {
 
 .quote {
color: #007f00;
+   font-size: 85%;
+   line-height: 85%;
 }
 
 span.p_header  { color: #2e8b57; font-weight: bold; }
-- 
2.7.0

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH 01/10] stick django version to 1.8

[Thomas Monjalon]

2016-09-07 10:42, Daniel Axtens:
> >> > --- a/requirements-prod.txt
> >> > +++ b/requirements-prod.txt
> >> > @@ -1,2 +1,2 @@
> >> > -Django>=1.8,<1.10
> >> > +Django>=1.8,<1.9
> >
> > Unfortunately, the requirement <1.9 does not download Django 1.8
> > but a release candidate of the version 1.9.
> > Is it the expected behaviour?
> 
> That's weird - no, I wouldn't expect that. I can try to find a work
> around for that if it would be helpful. 
> 
> To be honest I would have thought production deployments would use
> distro packages rather than pip - have you considered that route?

There are 2 issues with distro packages in my case:
- they are too old
- I use virtualenv to have a packaging separation between apps

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH] lib: Refresh nginx/uwsgi configuration

[Thomas Monjalon]

As stated in http://uwsgi-docs.readthedocs.io/en/latest/Nginx.html:
"
Unfortunately nginx is not able to rewrite PATH_INFO accordingly to
SCRIPT_NAME. For such reason you need to instruct uWSGI to map specific
apps in the so called “mountpoint” and rewrite SCRIPT_NAME and PATH_INFO
automatically
[...]
ancient uWSGI versions used to support the so called “uwsgi_modifier1 30”
approach. Do not do it. it is a really ugly hack
"

Replacing the uwsgi_modifier1 hack by a mount point seems to work.

Signed-off-by: Thomas Monjalon <thomas.monja...@6wind.com>
---
 lib/nginx/patchwork.conf | 1 -
 lib/uwsgi/patchwork.ini  | 5 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/nginx/patchwork.conf b/lib/nginx/patchwork.conf
index 5479496..1e69d1a 100644
--- a/lib/nginx/patchwork.conf
+++ b/lib/nginx/patchwork.conf
@@ -35,7 +35,6 @@ http {
 location / {
 include uwsgi_params;
 uwsgi_pass unix:/run/uwsgi/patchwork.sock;
-uwsgi_modifier1 30;
 }
 }
 }
diff --git a/lib/uwsgi/patchwork.ini b/lib/uwsgi/patchwork.ini
index fc0f0ed..04a9837 100644
--- a/lib/uwsgi/patchwork.ini
+++ b/lib/uwsgi/patchwork.ini
@@ -6,11 +6,16 @@ project = patchwork
 base = /opt
 user = www-data
 group = www-data
+url = /
 
 chdir = %(base)/%(project)
 pythonpath = %(base)/%(project)
 module = %(project).wsgi:application
 
+# rewrite PATH_INFO and SCRIPT_NAME according to mount-points (for nginx)
+manage-script-name = true
+mount = %(url)=%(module)
+
 master = true
 processes = 5
 # increase buffer size to avoid "502 bad gateway error"
-- 
2.7.0

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH 01/10] stick django version to 1.8

[Thomas Monjalon]

Hi,

2016-08-28 15:06, Daniel Axtens:
> Hi,
> 
> WEN Pingbo  writes:
> 
> > Avoiding below error:
> > django.db.utils.ProgrammingError: relation "patchwork_state" does not exist
> > LINE 1: ...dering", "patchwork_state"."action_required" FROM "patchwork...
> 
> Interesting. Stephen merged my patch
> https://github.com/getpatchwork/patchwork/commit/231966452f22dd344eabdd4f0722ce5463d1469a
> which should also solve this problem.
> 
> Could you rebase on top of master and see if this patch is still needed?
> 
> Regards,
> Daniel
> 
> >
> > Signed-off-by: WEN Pingbo 
[...]
> > --- a/requirements-prod.txt
> > +++ b/requirements-prod.txt
> > @@ -1,2 +1,2 @@
> > -Django>=1.8,<1.10
> > +Django>=1.8,<1.9

Unfortunately, the requirement <1.9 does not download Django 1.8
but a release candidate of the version 1.9.
Is it the expected behaviour?
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: Feedback on recent Patchwork update

[Thomas Monjalon]

2016-03-29 11:22, Finucane, Stephen:
> I think the recently merged "shift-select" patch will help [4]. To
> summarise, this lets you use the shift key to select a range of
> patches and is, to me, a clear usability boost. As for the general
> spacing, let's see if we can compress this further without reducing
> readability. This could also be a user configuration option, a la
> Gmail's cozy/compact UI setting.

Yes the "shift-select" is really a killer feature for the web interface.

I agree the spacing should be small, or at least have a preference
settings for compact mode.
I would add that the line "Submitted by" below the title seems useless
as the info is already at the top of the commit message section.

> > 3) Comments are now after the PATCH. This is nuts. That's the first
> > thing I want to see after the commit message! I want to see if people
> > have reservations or major feedback about the patch before I even
> > see the patch itself.

+1

I wonder wether the box to change some patch properties should be
duplicated between the last comment and the patch, to avoid scrolling
after reading the comments.

Another good feature would be to change the color and reduce the size
of the history in the comments (I mean lines starting with "> ") to
improve readability.

Thanks for improving patchwork
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH] models: Allow to unselect maintainer projects in user profile

[Thomas Monjalon]

The admin page for user profiles have a field "Maintainer projects"
to grant maintainer rights to an user.
It is a list of available projects.
When a project was selected, it was impossible to revoke.
It is now possible to unselect by clicking while holding the "Ctrl" key.

Signed-off-by: Thomas Monjalon <thomas.monja...@6wind.com>
---
 patchwork/models.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/patchwork/models.py b/patchwork/models.py
index 88af2f0..5686ec8 100644
--- a/patchwork/models.py
+++ b/patchwork/models.py
@@ -111,7 +111,7 @@ class UserProfile(models.Model):
 user = models.OneToOneField(User, unique=True, related_name='profile')
 primary_project = models.ForeignKey(Project, null=True, blank=True)
 maintainer_projects = models.ManyToManyField(
-Project, related_name='maintainer_project')
+Project, related_name='maintainer_project', blank=True)
 send_email = models.BooleanField(
 default=False,
 help_text='Selecting this option allows patchwork to send email on'
-- 
2.5.2

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: distributed tests of a patch

[Thomas Monjalon]

2015-09-24 13:57, Damien Lespiau:
> On Thu, Sep 24, 2015 at 02:34:10PM +0200, Thomas Monjalon wrote:
> > 2015-09-24 12:01, Damien Lespiau:
> > > On Thu, Jul 23, 2015 at 01:26:22AM +0200, Thomas Monjalon wrote:
> > > > When refreshing one of these views, it is possible to see the test 
> > > > progress,
> > > > i.e. how many tests are complete.
> > > > In this scheme, there is no definitive global test status.
> > > > The idea is to wait to have a common number of success and no error 
> > > > (removing
> > > > possible false positives) to consider a patch as good. This judgement 
> > > > is done
> > > > by the maintainers.
> > > 
> > > I'd really like some idea of test completion. I think it's quite key to
> > > even consider doing more work with the patch, make sure all tests have
> > > been run.
> > 
> > The goal is to be really open and distributed. It means new tests can spawn 
> > and
> > some of them may be removed or disabled without central management. It 
> > allows
> > to leverage a community for testing without management issues.
> 
> That's something debatable. If you are part of a community and have a
> separate test system, asking the admin (if you're not admin yourself) to
> add an entry for your test (giving a name, maybe contact email for that
> test, etc..) is not the end of the world?

I think an admin must give the right to an entity to send some test reports,
e.g. whitelisting the email. Then this entity manage its own set of tests.
Sometimes they can add or update a test, sometimes they can make some errors
and have the urgent need to disable a test sending some false positives.
It is important to give this entity the agility of managing which tests are
run in a reactive way. If they are not reactive enough, they can be removed
from the whitelist.
But asking to a central admin for each test enabling/disabling is clearly a
bottleneck leading to a failure of the distributed concept IMHO.

> It is true that that not caring about testing completion simplifies
> things though.

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH 00/51] Series aware patchwork

[Thomas Monjalon]

Hi,

2015-09-11 16:54, Damien Lespiau:
> Here a few initial patches to make patchwork understand series instead of just
> patches. This is not the end of the story, but a minimal-ish start to build
> upon. What the series does:
> 
>   - Parse mails and creates Series objects (what you would expect all mails
> part of the same git send-email are part of the same series)
>   - Display the list of series
>   - Display details about the series (eg. cover latter + list of patches)
>   - As first feature on top, add a way to assign a reviewer to that series

Thanks a lot for your work.

Is it possible to update A/R/T counters of every patches in the series when
tags are sent against the cover letter?
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: distributed tests of a patch

[Thomas Monjalon]

2015-08-19 11:33, Damien Lespiau:
 patchwork know about series first though, otherwise I don't think it
 makes much sense to test patches in isolation.

I think it makes sense to test every patches in a series.
Though I agree we need a simple method to apply previous patches of the series.
A series id could help.

[...]
   - Have some git integration where one can pull and apply a whole
 series to a tree (as the first step for testing the patches):
 $ git pw-am series 2341   # where 2341 is the series id of the
   # patchork instance configured in
   # .git/config

Seems good. Thanks

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH 04/10] models: Add 'status' model

[Thomas Monjalon]

Hi Stephen,

Thanks for your good work.

2015-07-29 09:58, Stephen Finucane:
 +class Status(models.Model):
 +Status for a patch.
 +
 +Statuses define a state for patches. This is useful, for example,
 +when using a continuous integration (CI) system to test patches.
 +

There is already class State associated to class Patch.
Don't you think TestStatus would be a better name?

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH 00/10] Add support for tests statuses

[Thomas Monjalon]

Hi Thomas,

2015-07-29 11:53, Thomas Petazzoni:
 On Wed, 29 Jul 2015 09:58:38 +0100, Stephen Finucane wrote:
  This series introduces support for patch statuses. These are results
  of tests and other automated checks executed on any given patch. Such
  tests and checks can range from unit tests and license validation to
  large integration and performance testing. These statuses can be
  provided by multiple users, thus allowing for a distibuted test
  infrastructure.
  
  This feature requires a number of changes, such as new models and
  extensions to the templates. Some new endpoints are provided for the
  XML-RPC API along with a minimal extension to the 'pwclient'
  application. It is envisioned that both this application and the
  broader collection of scripts provided with patchwork will be expanded
  on by the community as required.
  
  This feature is entirely optional and can be ignored by users if so
  desired.
 
 Rather than a concept of status, wouldn't it be better to simply
 associate tags to patches ?
 
 For example, when a patch successfully passes CI, you add a given tag
 to the patch, or when it fails CI, you add another tag. And the web
 interface would allow to filter the patches depending on which tag they
 contain (or not).

The goal is to have counters for Success/Warning/Failure as it is done
for A/R/T.
Note that A/R/T are not handled as tags because numbers are meaningful.

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH 04/10] models: Add 'status' model

[Thomas Monjalon]

2015-07-29 13:33, Finucane, Stephen:
  Having State and Status is confusing.
 
 What about getting rid of State? :) I haven't found any public patchwork
 project that modifies the default list of states, so I think a static
 choices field on 'Patch' would be a better option. I actually have a
 waffle.io ticket for myself and some work done to do this:
 
   https://github.com/stephenfin/patchwork/tree/draft/model-cleanup
 
 More immediately though, I'm fine with renaming this. Would Service be a
 suitable compromise or are you rigid on TestStatus?

I'm neither the maintainer nor the author of this patch, so I just suggest :)
Service or Check is also fine.

 I really don't like the double-barrel name tbh heh.

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: distributed tests of a patch

[Thomas Monjalon]

Hi,

Thanks Thomas Herbert and Stephen Finucane for the help and the previous
offline discussions.

2015-07-23 10:13, Thomas F Herbert:
 Second: We will add a column to the main page showing test status for 
 each patch ID with three counts for Success/Warning/Error
 
 Third: We will be updating the patch detailed view analogously to 
 headers show with summary descriptions of the submittted test results.
 
 Fourth: We will have an additional new main page showing incoming test 
 results indexed by patch_id with a list of incoming test results. 
 Clicking on each test result will show the longer test results generally 
 Jenkins console dumps (However there is nothing in this proposal that 
 maintains Jenkins or any other CI tool)

Why this fourth change is needed?
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: Feature request: delegating patches to others than maintainers

[Thomas Monjalon]

2015-07-20 15:27, Thomas Petazzoni:
 Currently, Patchwork only allows to delegate patches to developers who
 are registered as maintainers of the project in Patchwork. This is a
 bit annoying as maintainers in the Patchwork sense have the power to
 change the state of *any* patch.
 
 In the context of the Buildroot project, it would sometimes be nice to
 delegate the handling of a patch to a certain developer (who is neither
 the submitter of the patch nor a maintainer of the project).
 
 So do you think it would be possible to adjust the Delegate logic so
 that maintainers can delegate to all developers of the project, and
 once a patch has been delegated to a given developer, this develop gets
 the same rights as the submitter of the patch (i.e can change the
 status of the patch) ?

+1
It would be a great help for the DPDK project too.
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork