Re: Lyon meeting notes

[Dmitry Vyukov <dvyukov@google.com>]

On Fri, Nov 1, 2019 at 6:29 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Wed, Oct 30, 2019 at 09:35:08AM +1100, Daniel Axtens wrote:
> > > KR: write local command to work with patchwork.
> > We have a couple of local commands already, pwclient and git-pw. Is
> > there something new that would be helpful?
> >
> > As an aside, I know offline stuff has come up a few times, and I think
> > it should be reasonably straightforward to make a caching API client
> > that can buffer your requests until you're next online. I don't have any
> > cycles to do this, but I'm happy to help anyone who does.
>
> This is part of the tooling work that we discussed and I plan to have a
> more elaborate proposal finalized next week. We are hoping to fund the
> development of two closely related tools, one CLI and another using the
> browser interface, using a web server available over a localhost (or a
> local network) connection.

Hi Konstantin,

I am not sure if you are implying it here or not, but I would assume
it would be useful to run an actual "web" copy of this server over a
federated feed as well. Because... why not? it should be easy to do
and provide unified experience for online/local modes.

Otherwise looks good.

> The overall set of features for the web-interface would be:
>
> 1. Run the web interface locally in a container, to be accessed over
>    localhost
> 2. Use public-inbox feeds as the source of incoming patches, allowing to
>    pre-filter by:
>    - list-id
>    - from/to/cc
>    - keywords
>    - patch file path
> 3. Integrate natively with the local repository to allow the following
>    functionality:
>    - apply series directly to the repo, from the proper base-commit parent
>    - recognize patches that have already been applied and auto-archive
>      them as necessary (current kernel.org's patchwork-bot functionality)
> 4. Offer code-review features using the web interface (something
>    similar to gerrit), with outgoing email sent back out to the
>    submitter (plus list, cc's, etc), using the reviewer's own From: and
>    smtp server information
>
> For the lack of a better term, I'm calling it "local patchwork", though
> it's more likely to be a closely related spin-off that would hopefully
> share a lot of code with patchwork and be able to both benefit from
> upstream and to commit code back up for any shared functionality.
>
> Caveat: this is not finalized and I will be putting up the proper
> proposal up for a discussion here. Since we're talking about both a CLI
> and a web interface to largely the same functionality, it's possible
> that instead of attempting to run patchwork in a container, it would
> make a lot more sense to run a daemon exposing a REST API that both the
> CLI tool and the web tool would consume. However, this would require
> rewriting a whole lot of things from scratch and would end up a lot more
> difficult to both fund and develop -- which is why I'm leaning towards
> adding these features to Patchwork instead.
>
> -K