Thread: Volunteering as Commitfest Manager
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. I have an interest in and long experience in each of those areas, so that makes sense for me. The titles refer to the categories on the CF application, self-selected by patch authors, not an increased remit to wade in on anything that appears to fall into those categories. Patches need an eventual committer anyway, so this is a reasonable way of having the process be managed by the eventual committer. I don't see the role as an authoritarian one, so I will happily pass over patches to other committers who may wish that and/or call for help from particular people as required. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
* Simon Riggs (simon@2ndQuadrant.com) wrote:
> So it makes sense to split that role between multiple people.
I agree that it'd be good to have multiple people supporting the CF.
I've been considering volunteering to be part of such a group for a
given CF.
> I volunteer to be the CF manager for Replication, and also for
> Performance.
I dislike the idea of splitting up the duties along these lines.
However, if others are willing to handle it that way and we can get
coverage for all the CF categories, I wouldn't object. The reason
that I dislike this is simply that the actual work of the CF manager
isn't really distinguished in any way based on if it's a Replication
patch or a Performance patch or some other patch. Most of the CF work
is about following-up with reviewers and authors and committers.
I feel this kind of "I'd prefer to be working on what interests me/what
I'm knowledgable in" concept is typically addressed through the
self-volunteer reviewers, where someone will mark themselves down as a
reviewer for a specific patch because it's what they're interested in.
Additionally, reviewers, when volunteering, can, and often do, ask for
specific kinds of patches (though it's usually driven more by 'size' or
'complexity' than category). That feels like a better place to put this
than at the CF manager level.
> Patches need an eventual committer anyway, so this is a reasonable way
> of having the process be managed by the eventual committer.
I also don't like the idea that committers, when supporting a
commitfest, would only be involved/working on specific categories of
patches. I feel that part of the idea of a commitfest is to have
individuals, particularly committers, looking at patches which fall
outside of what they're currently working on (since they can/could
commit those things more-or-less anytime).
My thinking (and I have no idea how others feel or if anyone's even
considered it this way) is simply that part of the responsibility of a
committer would be that they help get non-committer patches, which are
good for PG, submitted through the right process, etc, but which may
not be of specific interest to any given committer, committed. If a
patch is already of interest to a committer because it hits on a
hot-spot with them then that patch doesn't really *need* a CF to get
done.
Thanks,
Stephen
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.
regards, tom lane
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. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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