Stolen from
http://subversion.apache.org/docs/community-guide/roles.html#patch-manager
Patch Manager
$project usually has a Patch Manager, whose job is to watch the
dev@ mailing list and make sure that no patches "slip through the
cracks".
This means watching every thread containing "[PATCH]" mails, and
taking appropriate action based on the progress of the thread. If
the thread resolves on its own (because the patch gets committed,
or because there is consensus that the patch doesn't need to be
applied, or whatever) then no further action need be taken. But if
the thread fades out without any clear decision, then the patch
needs to be saved in the issue tracker. This means that a summary
of any discussion threads around that patch, and links to relevant
mailing list archives, will be added to some issue in the tracker.
For a patch which addresses an existing issue tracker item, the
patch is saved to that item. Otherwise, a new issue of the correct
type — '$DEFECT', '$FEATURE', or '$ENHANCEMENT' (not '$PATCH') —
is filed, the patch is saved to that new issue, and the "patch"
keyword is recorded on the issue.
The Patch Manager needs a basic technical understanding of
$project, and the ability to skim a thread and get a rough
understanding of whether consensus has been reached, and if so, of
what kind. It does not require actual $project development
experience or commit access. Expertise in using one's mail reading
software is optional, but recommended :-).
The current Patch Manager is: $person
I really like the basic outline, but what I feel is missing, is the
notion of watching $issuetracker. Often we have patches getting lost
in there. So our patch manager should also look out for $PATCH issues
and make sure they are followed up, or assigned, or whatever.
Thoughts? Comments? Ideas?
I happily welcome all of these.
So long,
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE