You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Igor Galić <i....@brainsware.org> on 2011/11/16 09:28:10 UTC
[DRAFT] Wanted: Patch Manager
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 <$contact>
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
Re: [DRAFT] Wanted: Patch Manager
Posted by Nick Kew <ni...@webthing.com>.
On 16 Nov 2011, at 08:28, Igor Galić wrote:
> Stolen from
Stolen from the reply I just posted to another dev list ;)
> Patch Manager
Sounds like a role for an Igor.
(as any Pratchett fan will instantly understand :D )
Seriously, though, while it's a Good Thing to ensure patches
don't slip through the cracks, it's not clear that specifying such
a role really adds anything. If a explicit [PATCH] is posted to
this list I think our natural reaction would already be to suggest
the poster opens a ticket in the issue tracker.
But if you'd like to take explicit responsibility that's fine!
--
Nick Kew
Re: [DRAFT] Wanted: Patch Manager
Posted by Daniel Ruggeri <DR...@primary.net>.
On 11/16/2011 2:28 AM, Igor Galić wrote:
> 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.
Yes, agreed - we always do ask for an issue to be opened up, but
sometimes those can also fall through the cracks, too. The first part of
the email seems pretty straight forward since we don't seem to really
get many emails on dev@ containing patches that don't end up with an
associated issue. Having a "bugzilla cop" to identify duplicate issues,
pester the dev list about lingering issues, provide gentle reminders of
issues in progress if they stall, close out "junk" and "how to" tickets
and even bring up issues opened in the tracker that never had a
corresponding dev discussion would be pretty great.
I'm more than happy to help in this role, but don't always consistently
have the time available to keep as sharp an eye on the tracker as I
would like.
--
Daniel Ruggeri