Re: Volunteering as Commitfest Manager - Mailing list pgsql-hackers

On Wed, May 25, 2011 at 10:32 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, May 25, 2011 at 3:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Simon Riggs <simon@2ndQuadrant.com> writes:
>>> I hear that CF manager is a difficult role for a single individual.
>>> So it makes sense to split that role between multiple people.
>>
>>> I volunteer to be the CF manager for Replication, and also for
>>> Performance. ...
>>> Patches need an eventual committer anyway, so this is a reasonable way
>>> of having the process be managed by the eventual committer.
>>
>> ISTM that we really want the CF manager to be somebody who is *not*
>> directly involved in reviewing or committing patches.  It's a distinct
>> skill set, so there is no reason why it's a good idea for a committer
>> to do it.  And we need to get the CF work load more spread out, not more
>> concentrated.
>
> I agree it makes sense if a non-committer performs the role. If a
> committer does take the role, I would volunteer to split the role and
> for me to work on the suggested areas.

I think it would be really valuable for you to get more involved in
reviewing some of the patches, whether you end up doing any of the
CommitFest management tasks or not.  In the past, your involvement has
been light; but we have a limited number of people who are qualified
to do detailed technical reviews of complicated patches, and more help
is very much needed.

I share the opinion expressed upthread that in an ideal world, we
would not have major reviewers or committers also doing CommitFest
management work, but in some sense that's an ideal world that we don't
live in.  Greg Smith and Kevin Grittner, both of whom have
successfully managed CommitFests in the past, also contribute in many
other ways, and I would not want to say either that those other
contributions disqualify them from managing CommitFests, or that
because they are managing the CommitFest they should suspend their
other involvement.  Either rule would be a random bureaucratic
obstacle that accomplishes nothing useful.  So I don't see the fact
that you are a committer as a reason why you can't or shouldn't help
with CommitFest management - if, for example, you don't want to review
patches yourself, but you do want to help organize other people to
volunteer to review patches, we should accept the contribution that
you're willing to make rather than insisting that you should make some
other contribution instead.

So, what I think is important is to understand exactly what you'd like
to volunteer to do, and see whether that fits in well with what other
people want to do.  Typically, at the beginning of the CommitFest,
there are a bunch of people who volunteer to be assigned a patch.
This task is likely best done by one person who has the entire
CommitFest in mind - in particular, I have found that it's a good idea
to tackle the most significant patches first; the little stuff can be
picked off at the end without much trouble, and is rarely what holds
the process up.  However, all of the other CommitFest management tasks
can be easily split across multiple people.  The main task, and where
the vast majority of the work goes, is in following up on patches
where discussion has died off or failed to reach a conclusion, and
encouraging the patch author to resubmit or the reviewer to re-review
or a committer to consider it for commit or just marking it Returned
with Feedback if there's insufficient consensus and/or time and/or
motivation to get it finished up in a month's time.  We've allowed
this to become the problem of a single and rather monolithic
individual, but that system sucks, and I have no desire to perpetuate
it.  It sucks for that individual because it's a lot of work, and it's
difficult to keep many unrelated patches in your head at the same
time; and it sucks for everyone else, because about half the time that
one monolithic individual finds that the rest of their life interferes
with PostgreSQL, or the other things they are doing for PostgreSQL
interfere with their role as CommitFest manager, and they don't do it
as well as it needs to be done to really make things run smoothly.

Therefore, if you'd like to volunteer to help keep on top of the
replication and performance patches, and make sure that they are
getting followed up on regularly, I think that would be excellent.  We
tried before having a position of "patch-chaser" or "assistant
commitfest manager by topic" for the September of 2009 CommitFest, but
it wasn't entirely successful.  It's time to revisit that concept,
because we're not always going to find one person who can devote 40+
hours to managing a CommitFest, and even when we can, it's not exactly
accomplishing our goal of decentralizing the work.  It's better than
the "Tom do everything" approach, and we do have a lot of people
helping review now, but there are still two or three people per
CommitFest burning a lot of midnight oil.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company