Patchwork (was Re: Governance revisited)

[Ge van Geldorp]

> From: Alexandre Julliard <julliard at winehq.org>
> 
> If you expect 
> anything to happen, you'll need to make much more concrete 
> suggestions, and provide examples to make us understand how 
> what you are suggesting would work in practice

Fair enough. Some disclaimers upfront: I'm basically thinking out loud, I
have no idea what your typical workflow looks like. I'm also not restrained
by any knowledge of emacs and what can be done in its plugins, macro's,
user-defined commands or whatever they're called. But I know I could code
the proposal below in e.g Perl or C, so I guess it should be possible in
Lisp also. Who's going to code that is a different matter altogether, let's
first see if we can think of a solution which would work.

Let's assume a patch is submitted to wine-patches. A bot would receive it
and store it in a database (Patchwork already seems to do a fine job on
this). The bot could do some simple checks, like does it apply cleanly, no
C++ comments, whatever automatic checks we can come up with. If one of the
checks fails, the status would be set to RFC (Request For Change, I'm using
the Patchwork statuses here) and the author would receive an automatic email
explaining what's wrong, otherwise the status would be set to New. Note that
this should save you some time, weeding out "obviously" wrong patches.

On to your workflow. You'd issue a Meta-Ctrl-Shift-whatever emacs command.
Behind the scenes, this would send a request to the webserver which would
reply with a list of queued patches. This list could be sorted by a score.
Authors who consistently submit good patches would get a higher score than,
well, me. This score could be computed as the number of accepted patches
minus the number of rejected patches. A patch already reviewed (and
recommended) by a subsystem maintainer could get a real big score boost so
it ends up near the top of the list. Patches which have been in the queue
for a few days could get extra points. Patches with RFC status wouldn't be
shown at all or get a very low score. Anyway, you end up with a list of
patches on your screen with the least problematic near the top. This should
help ensure that these get through pretty quickly.

So you select a patch which is then retrieved from the server. It could be
automatically applied, a build started, whatever suits you best. Comments
made on it by other developers could be shown to you. After testing is
complete, you issue a "decision" command. You can decide to accept the
patch, that would send an "accept" message to the webserver and perhaps it
could be comitted to your git repo. If the patch needs more work, you'll be
prompted for a message. That message will be mailed to the author with a
copy to win-devel and it will be sent to the webserver which will change the
patch status to RFC. If you think the patch is beyond hope it can be
rejected outright (again with a message to author and wine-devel). Or you
can decide not to decide on it today and sleep on it for a night. Then the
patch will just show up in the list of pending patches again tomorrow, with
a little bit higher priority (since it has been in the queue longer).

Back to the list of pending patches, repeat.

> and how it would be different from what we are doing now.

It would make sure the author always receives some kind of feedback (either
from the bot, other developers or yourself) and would make sure patches
don't get lost (patches are automatically entered into the system and only
leave the system when the author withdraws them or when you make a final
decision).

Ge van Geldorp.