Re: [PATCH] views: Don't render token section of user profile if REST API disabled

2017-12-18 Thread Andrew Donnellan
On 19/12/17 16:41, Andrew Donnellan wrote: In profile.html, if settings.ENABLE_REST_API == False, trying to render a link to the generate_token page will raise a NoReverseMatch exception, so we shouldn't render that. In any case, if the REST API is disabled, we really shouldn't render the API tok

[PATCH] views: Don't render token section of user profile if REST API disabled

2017-12-18 Thread Andrew Donnellan
In profile.html, if settings.ENABLE_REST_API == False, trying to render a link to the generate_token page will raise a NoReverseMatch exception, so we shouldn't render that. In any case, if the REST API is disabled, we really shouldn't render the API token section of the page at all. Only render t

[PATCH v2] models, templatetags: Make tag count column in patch list optional per tag

2017-12-18 Thread Andrew Donnellan
Add a field, show_column, to the Tag model to determine whether the tag gets a tag count column in the patch list view. This allows the creation of tags that will be collated when generating mboxes but won't take up space in the patch list. show_column will default to True to maintain the current

Re: Continuous integration with buildbot

2017-12-18 Thread Andrew Donnellan
On 19/10/17 14:10, Russell Currey wrote: We were keen on supporting multiple CI backends (including Buildbot), but Andrew and I have been far too busy recently to work on it. It's definitely technically feasible in any case, and there's some code/ideas you could steal. I'm hoping to have some

[PATCH] models, templatetags: Make tag count column in patch list optional per tag

2017-12-18 Thread Andrew Donnellan
Add a field, show_column, to the Tag model to determine whether the tag gets a tag count column in the patch list view. This allows the creation of tags that will be collated when generating mboxes but won't take up space in the patch list. show_column will default to True to maintain the current

Re: [PATCH] RFC: Monkey-patch Django performance bug

2017-12-18 Thread Andrew Donnellan
On 26/09/17 15:37, Andrew Donnellan wrote: Currently looking at this. For the ozlabs.org case, I'm also looking at getting the patch backported straight into Debian. Asked around on IRC - it seems that upstream's backporting policy is quite restrictive when it comes to anything that's not se

Re: [PATCH] xmlrpc/patch_list: only fetch required fields

2017-12-18 Thread Andrew Donnellan
On 29/09/17 00:19, Daniel Axtens wrote: OzLabs noticed *massive* slowdowns in queries like this one: SELECT "patchwork_submission"."id", "patchwork_submission"."msgid", "patchwork_submission"."date", "patchwork_submission"."headers", "patchwork_submission"."submitter_id", "patchwork_submission".

Re: [PATCH] RFC: Monkey-patch Django performance bug

2017-12-18 Thread Andrew Donnellan
On 08/09/17 18:41, Stephen Finucane wrote: I don't know what Django's backport policy actually is, but it would appear both 1.8 (LTS) and 1.10 are still in extended support [1]. This performance regression does seem like a viable candidate for v1.10.8 (based on how we do thing in OpenStack land a

Events for new comments for a patch series?

2017-12-18 Thread Don Zickus
Hi, I was playing with the events REST API interface and realized how convenient the 'series-completed' category is. I was curious if there is also a way to be notified if a new comment arrived for a patch series. We tend to use replies to patches as tags for meta info. For example, acked-by, n