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