Patchwork (was Re: Governance revisited)

[Jeremy White]

Troy Rollo wrote:
> As I speculated, the reason the PPC64 Patchwork example was so out of date was 
> that the PPC64 list had been folded into the vanilla PPC list, however the 
> big problem right now is that Patchwork is "extra work" for maintainers, so 
> right now they don't want to use it.

Ouch.  This is what I fear.

> Jeremy - do you have any documentation for this from the last time you looked 
> at implementing patch managemen, and if so is it up to date for Git?

Well, despite my doubts of the usefulness of this, I remain quite
interested in trying to improve the process.

I should warn you, though, I'm famous within CodeWeavers for having
'Clever Ideas That No One Uses' (TM).  I fear that a
patch tracker is just one such.

But here is a private thread between myself and Alexandre, in which
I noodled on a possible approach, and in which Alexandre shot me
down <grin>.

-------------------

Okay, so here's is my next Clever Idea That Isn't Used (CITIU):

  Assumptions:

    1.  We can write a utility that lets us compare a winehq commit
        message to a wine-patches email and see if there is a 'match'.
        100% isn't required, but some nice non zero number is.

        A key requirement is that there are near zero false hits.


    2.  We can write a utility that lets us look at an email
        on wine-devel and see if it is a reply to a patch on wine-patches.

        Again, the assumption is that 100% match isn't needed.  For this one,
        though, we should be able to do much better (as we'll have a message id usually).

        We also can tolerate very few false hits here as well.


  Tasklist:

    1.  Build a process that receives email from wine-patches, wine-devel,
        and wine-cvs.  Each new email to wine-patches goes into a database.

    2.  Each email from wine-cvs looks for a patch in the db, and deletes
        a matching patch.  (Or perhaps sets status to 'committed').

    3.  Each email from wine-devel looks for a matching patch in the db,
        and if there is a hit in the db, we delete it as well.
        (Or perhaps set status to 'replied').

    4.  We write a web page that displays all patches in the db, with
        some nice filters.  It has a button to allow someone to change a
        patch status (that way, we can clean up for the cases where a human
        being can see that there was a match, but the process couldn't).


  Hoped for Result:

    1.  You do nothing new.

    2.  Other wine-hackers can see what patches are apparently headed
        through cracks, and get a chance to jump on them.

    3.  People who submitted a patch have a page to see the status,
        and get a clue as to what might have happened to it.


  Possible futures:

    1.  We could give you a 'urk!' button somewhere that
        would actively flag a patch as something you'd appreciate
        someone else think about; that could raise them up.

        If we do this as a daemon, we could probably even do it
        trivially as a reply-to patch-daemon at winehq.org right out
        of emacs.

        (We can get even fancier here; the sky is the limit,
        but I fear too much cleverness).


  Issues I see:

    1.  Yet Another Clever But Unused Idea

    2.  Private emails are unaccounted for.  Are they a major factor?

    3.  Haven't proven our assumptions yet


-----------------

To the private email issues, Alexandre replied:

There are a fair number of such cases, yes. Not so much the bad
patches but the corrupted/mangled/doesn't apply patches; I don't want
to fill wine-devel with "this patch is corrupted please resend". And I
know other people often reply in private too, for instance when
someone forgot the attachment.

Also there are a lot of cases where a patch won't get committed but
shouldn't be in the list, people often supersede their own patches, or
two people fix the same thing in two different ways, etc.  So I feel
it would require active monitoring to keep the list somewhat up to
date, and I don't know that there would be people willing to do that
in the long run.

----------------

I guess it's the latter point that is key.  We can automate
some of this, but in the end, some human monitoring will be
required.

Being a foolish optimist, I don't see any harm in trying, particularly
if we focus on benefit #1 (Alexandre doesn't have to do anything :-/).

But I should point out I'm not rushing to volunteer to write
the daemon or revise Patchwork or actually do any useful work...

Cheers,

Jeremy