Skip to content
Damien Lespiau edited this page Sep 30, 2015 · 14 revisions

A dumping ground for now, needs some organisation.

  • Series

    • Multiple patches without cover letter
    • Series command in pwclient
    • Way to know when a series has been fully posted (including all patches) to be handed over some testing infrastructure (that could be a simple script)
    • Add a way to express dependencies between series (series 1 depends on series 2 being applied)
  • ml -> patchwork communication

    • auto-supersede according to patch subject and in-line revision

    • Ensure patches that have been merged get marked as such automatically. OpenEmbedded is using the pre-push hooks that are supposed to do this, but if the patch has changed even slightly during merging, the hook script won't find it and it has to be manually marked.

      Carl/Richard suggesting matching the subject. We could also add some fuzz on the subject matching in case a typo has been fixed when applying (Say using the Levenshtein distance)

      Need example patches to characterize the failure cases and see what we can do.

    • have a way to discard a series by answering its root mail

    • Make sure patches sent from a separate person than the patch author is correctly attributed (From: in the body of the message)

  • patchwork -> ml communication

    • If a patch/series is reviewed, send Reviewed-by tag to ml
    • Allow reviewing in the browser and send a mail with the comments (big task, somewhat hand-wavy)
    • When the patch is merged, send a notification on the ml
  • patchwork

  • Review

    • Assign series with pwclient
    • assignment/due dates for review
    • auto-poke mail to reviewer+author+manager on overdue review (configurable number of days)
    • Notification to the maintainers when a series is fully reviewed?
    • Make a diff between versions of a series?
  • Bugs

    • filter bug when Person has no name
    • Fix the bug(s) where some patches sent to the mailing list just don't show up in patchwork. A common trigger for this seems to be where non-English characters are in the submitter's name or patch subject, but it may not be the only cause.
  • pwclient

    • XML-RPC doesn't have a good way two do server->pwclient communication, for instance, we can't really have a pwclient waiting for an event (say "a new series appeared on the ML") -> Switch to web sockets? (gevent?)
    • Any features added to patchwork server side be accessible through the pwclient
  • States

    • Things like "RFC" shouldn't be in the state list and probably not shown by default in the list of pending patches needed review (Daniel: Yeah, RFC patches could get autodeprecated. That would make patches tagged as RFC a bit more useful for high-level design discusssions since they wouldn't clog patchwork any more)

More input from Jani

  1. Auto obsolete patches after they get old. If the patch didn't get merged in 3-6 months, it's not going to get merged. (This could be scripted if the RPC interface was better, but I wouldn't mind having this server side.)

  2. Think about adding proxy support for pwclient. (For an example, see the python-bugzilla client [1].) For now, I use this wrapper:

    #!/bin/sh export LD_PRELOAD=libproxychains.so.3 exec ${HOME}/bin/pwclient.py "$@"

More input from Daniel

I think one fairly immediate thing we could do which should have an extremely low false-positive ratio is deprecate any patch when there is an in-reply-to of a new patch to that old patch. And it needs to do that with arbitrary nesting in case of discussions.

The only problem is that without a cover letter git send all patches in a series as a reply to the first one, so we'd need to filter that out. But that should be possible by detecting the n/m sequence.

One awesome feature would be an automatic Superseedes: and Discussion: link added to the patchwork patch. The first one would link to a stable mail archive by msg id of the previous version of that patch, the 2nd to the discussion of the current patch (cover letter maybe even). E.g.

Extend that to tags in general, i.e. everything that looks like a Mail header in the body of a reply. We have Bugzilla: References: and OTC-Jira:, vpg uses gerrit review tags and there's piles of other stuff floating around.

Done

  • remove signature automatically
Clone this wiki locally