[Patchew-devel] [PATCH 00/16] RFC: Queue, MAINTAINERS and watched query

Fam Zheng posted 16 patches 3 weeks ago
Failed in applying to current master (apply log)
tests/patchewtest.py                         |   5 +-
tests/test_testing.py                        |  38 ++-
www/templates/base.html                      |   3 +
www/templates/my-queues.html                 |  82 +++++++
www/templates/series-detail.html             |  32 ++-
www/templates/series-list.html               |   8 +
www/views.py                                 |   2 +-
21 files changed, 534 insertions(+), 125 deletions(-)
create mode 100644 api/migrations/0040_review_to_queue.py
create mode 100644 api/migrations/0041_auto_20181120_0636.py
create mode 100644 api/migrations/0042_watchedquery.py
create mode 100644 api/migrations/0043_message_maintainers.py
create mode 100644 tests/data/0025-foo-patch-review.mbox.gz
create mode 100644 tests/data/0026-bar-patch-standalone.mbox.gz
create mode 100644 tests/data/0027-foo-patch-based-on.mbox.gz
create mode 100644 www/templates/my-queues.html

[Patchew-devel] [PATCH 00/16] RFC: Queue, MAINTAINERS and watched query

Posted by Fam Zheng 3 weeks ago
I refreshed my queue branch from a year ago, in a slightly different way. This
more or less makes it possible to realize what Markus asked for: watch for
patches touching certain files (as indicated by MAINTAINERS file) and
automatically notify him if not already in Cc.

The user story basically consists of four parts.

1) A logged in user creates a "watched query", by accessing (once we merge this)
   http://next.patchew.org/search?q=maint%3Ame+%21cc%3Ame and clicking the "Watch
   query" button. The search query will be saved for the user in the database.

2) Once a new patchset is uploaded by the importer, and post-processed by the
   applier, which also collects the associated maintainers by invoking
   .scripts/get_maintainer.pl.

3) The watched query is run against this new patchset. If it is included in the
   query, it is automatically added to the user's queue named 'watched'.

4) An event is generated upon the addition, which is configured as a source for
   email notifications just like testing reports. In the template, To/Cc addr
   of the original message is tested. Depending on if or not the user's email
   is in it, an email from no-reply@patchew.org to the user's address is sent,
   in reply to the original message, to catch attention from the users INBOX.

What is missing is the isolation between the existing maintainers role that
takes care of the testings etc, and the new maintainer role that is only
interested in receiving above notifications. Any comments on how we should do
that? Of course the role separation and fine-grained permission is only a small
part of the problem, the bigger one is how to provide better interface and hide
the email config and templating details.

Maybe the solution is to package the feature (into that "watch query" button)
and just send the notifications when it makes sense?

Do we want the applier to create and maintain a git tree/tag for each queue?

What kind of user facing commands do we want on patchew-cli? Downloading and
applying a queue?

Other comments, ideas, feedback?

Fam Zheng (16):
  models: Add project name to Message __str__
  testing: Fix bugs that new reviewed-by tags trigger retest
  mod: Pass request in render_page_hook
  template: Simpify op.icon default
  Generalize Review model to Queue
  maintainer: Queue operations in extra ops
  model: Introduce WatchedQuery
  Add "Watch query" button to search result page
  search: Add query_test_message
  maintainer: Update watched queue when getting new message
  www: Add /my-queues page
  maintainer: Add MessageQueued and MessageDropping events
  git: Remove unused code for server side git
  model: Add and populate Message.maintainers
  search: Introduce maintained-by:NAME term
  maintainer: Add maintainers status to series details

 api/migrations/0040_review_to_queue.py       |  19 ++
 api/migrations/0041_auto_20181120_0636.py    |  40 ++++
 api/migrations/0042_watchedquery.py          |  26 +++
 api/migrations/0043_message_maintainers.py   |  22 ++
 api/models.py                                |  22 +-
 api/search.py                                |  31 ++-
 mods/footer.py                               |   2 +-
 mods/git.py                                  |  46 +---
 mods/maintainer.py                           | 233 +++++++++++++++----
 mods/testing.py                              |  17 +-
 patchew-cli                                  |  31 ++-
 tests/data/0025-foo-patch-review.mbox.gz     | Bin 0 -> 1417 bytes
 tests/data/0026-bar-patch-standalone.mbox.gz | Bin 0 -> 1558 bytes
 tests/data/0027-foo-patch-based-on.mbox.gz   | Bin 0 -> 1421 bytes
 tests/patchewtest.py                         |   5 +-
 tests/test_testing.py                        |  38 ++-
 www/templates/base.html                      |   3 +
 www/templates/my-queues.html                 |  82 +++++++
 www/templates/series-detail.html             |  32 ++-
 www/templates/series-list.html               |   8 +
 www/views.py                                 |   2 +-
 21 files changed, 534 insertions(+), 125 deletions(-)
 create mode 100644 api/migrations/0040_review_to_queue.py
 create mode 100644 api/migrations/0041_auto_20181120_0636.py
 create mode 100644 api/migrations/0042_watchedquery.py
 create mode 100644 api/migrations/0043_message_maintainers.py
 create mode 100644 tests/data/0025-foo-patch-review.mbox.gz
 create mode 100644 tests/data/0026-bar-patch-standalone.mbox.gz
 create mode 100644 tests/data/0027-foo-patch-based-on.mbox.gz
 create mode 100644 www/templates/my-queues.html

-- 
2.17.2

_______________________________________________
Patchew-devel mailing list
Patchew-devel@redhat.com
https://www.redhat.com/mailman/listinfo/patchew-devel

Re: [Patchew-devel] [PATCH 00/16] RFC: Queue, MAINTAINERS and watched query

Posted by Paolo Bonzini 2 weeks ago
On 21/11/18 03:08, Fam Zheng wrote:
> I refreshed my queue branch from a year ago, in a slightly different way. This
> more or less makes it possible to realize what Markus asked for: watch for
> patches touching certain files (as indicated by MAINTAINERS file) and
> automatically notify him if not already in Cc.
> 
> The user story basically consists of four parts.
> 
> 1) A logged in user creates a "watched query", by accessing (once we merge this)
>    http://next.patchew.org/search?q=maint%3Ame+%21cc%3Ame and clicking the "Watch
>    query" button. The search query will be saved for the user in the database.
> 
> 2) Once a new patchset is uploaded by the importer, and post-processed by the
>    applier, which also collects the associated maintainers by invoking
>    .scripts/get_maintainer.pl.
> 
> 3) The watched query is run against this new patchset. If it is included in the
>    query, it is automatically added to the user's queue named 'watched'.
> 
> 4) An event is generated upon the addition, which is configured as a source for
>    email notifications just like testing reports. In the template, To/Cc addr
>    of the original message is tested. Depending on if or not the user's email
>    is in it, an email from no-reply@patchew.org to the user's address is sent,
>    in reply to the original message, to catch attention from the users INBOX.

Can you explain how this part would be configured?  Especially the
"depending if or not the user's email is in it" part.

> What is missing is the isolation between the existing maintainers role that
> takes care of the testings etc, and the new maintainer role that is only
> interested in receiving above notifications.

Why is there a conflict?  I understand that the new functionality is for
any logged-in user, including getting email.  As long as there Maybe
it's just a naming issue?

Perhaps one possibility is removing merged patches from the special
queues (accept/reject/watch), using a MessageMerged event.  Also adding
an "empty queue" button to the "my queues" page.  Otherwise looks great.

> Do we want the applier to create and maintain a git tree/tag for each queue?

Maybe later, but it's not required.

> What kind of user facing commands do we want on patchew-cli? Downloading and
> applying a queue?

As a start, even just listing the git tags should be enough for the user
to script it.  Maybe a generic "formatted search" like "git log
--pretty=format:..."?

But overall: it's awesome. :)

Paolo

_______________________________________________
Patchew-devel mailing list
Patchew-devel@redhat.com
https://www.redhat.com/mailman/listinfo/patchew-devel