Governance revisited (Wineconf report)

[Ge van Geldorp]

> From: Kai Blin
>
> Now, getting back to the patch submission process, you're talking about a 
> patch management system. How would that look like, in your opinion. We
were 
> discussing a couple of ideas, but in the end figured that most of those
would 
> slow down the submission speed of patches that are accepted.
>
> Our idea was to have patches be recieved by the subsytem maintainers, and 
> Alexandre would only apply patches he got from those guys. We voted that
one 
> down.
>
> Now I would be interested in your idea for such a system. I figure that 
> writing an emacs frontend won't be too troublesome if it's reasonably 
> designed, so let's ignore that for now.

A patch management system isn't exactly a new idea. It came up last year,
during the same type of discussion we're having now (and it will probably
come up next year when we have the same discussion again). See e.g.
http://www.winehq.org/pipermail/wine-devel/2005-September/039837.html and
note this sentence: "However, it became clear that the requirements were
fairly substantial (the tight emacs integration became our first clue :-/),
and that project got back burnered."

The users of such a patch management system would fall into 3 categories:
Developers/patch submitters, subsystem maintainers and Alexandre. I can take
a guess at what subsystem maintainers and Alexandre would want from such a
system, but of course I can only really speak as a patch submitter.
My primary requirements would be to be able to:
- Submit a patch
- Specify a subsystem
- Keep track of its progress
- Resubmit after receiving feedback
- Get an overview of patches in the queue
- Apply a queued patch to my working copy
- Provide feedback to others
- Withdraw a patch
In addition to the patch submitter requirements, subsystem maintainers would
probably like to be able to:
- Get an overview of patches relevant to their subsystem
- Recommend a patch for inclusion
In addition to all of the above, I guess Alexandre would need to be able to:
- Get an overview of recommended patches
- Commit a patch
- Reject a patch
- All from within emacs

Moving on to implementation, I see a set of database tables giving a patch
the following attributes:
- Submitter
- Short description
- Status (Queued, Waiting for developer, Recommended, Withdrawn, Committed,
Rejected)
- Subsystem
- Patch text (multiple versions, to allow resubmits and still keep a
history)
- Comments

Some status changes are restricted (e.g. only a subsystem maintainer would
be able to recommend a patch). Everyone would be able to submit a patch,
which would initially have Queued status. When feedback is provided, the
feedback provider (anyone) could change the status to Waiting for developer.
If a patch is in "Waiting for developer" status too long (say a month) it
could be automatically rejected. When "Waiting", the submitter could provide
a new version or respond with a comment, setting the status back to Queued
again. Or he could decide to Withdraw the patch. When a patch makes it into
the tree it will gain the most holy of all statuses, Committed. I envision
manually Rejecting a patch to be a pretty rare case, normally feedback would
be provided and the Waiting status would be set. Uncommittable patches would
then exit the system via the automatic clean up (in "Waiting" too long) or
via a Withdraw.

The heart of the system would be a couple of web pages. However, not
everyone likes web pages and the current system with mailing lists does have
its strong points too. So, there could be a two-way gateway between the web
system and the mailing lists. If a patch is submitted via the web, it could
be sent out via wine-patches too. If a patch comes in via wine-patches, it
could be added to the database automatically (when that doesn't succeed a
notification is sent to the author). Same for comments, they could be fed
from the web page to wine-devel.

If there is genuine interest to make this work I could put up a few mock
webpages to get a better idea of how it would work.

Gé van Geldorp.