On 11 February 2015 at 21:11:25, Chris Douglas
(cdoug...@apache.org<mailto:cdoug...@apache.org>) wrote:
+1; ChrisN's formulation is exactly right.
The patch manager can't force (or shame) anyone into caring about your
issue. One of the benefits of RTC is that parts of the code with a
single maintainer are exposed. If you can't find collaborators, either
(a) this isn't the right community for that module or (b) the project
needs to acknowledge and address the "bus factor" [1] for that code.
By observing and directing review, the patch manager accumulates
context most contributors don't have.
At the same time, if only 1 person is looking at a part of the codebase &
submitting patches, they have inherently recused themselves from reviewing on
their own patches. Ideally you want >1 committer tracking a topic. That's
someone with competence in the area too, obviously; a barrier to participation
in the corner areas.
Does anyone want to work with INFRA to test Crucible? It looks like
Ambari started exploring it last year [2]. From David's response, it
sounds like they'd be willing to work with a project to experiment,
but most requests have been for Gerrit. -C
[1] http://en.wikipedia.org/wiki/Bus_factor
[2] https://issues.apache.org/jira/browse/INFRA-8430
started with https://issues.apache.org/jira/browse/INFRA-9152 , though I'm not
sure the diff between fisheye and cruicible here; they seem blurred
On Tue, Feb 10, 2015 at 1:19 PM, Chris Nauroth <cnaur...@hortonworks.com> wrote:
> I don¹t anticipate a patch manager introducing a new bottleneck.
>
> As originally described by Chris D, the role of the patch manager is not
> to review and commit all patches in an assigned area. Instead, the
> responsibility is queue management: following up on dormant jiras to make
> sure progress is made. This might involve the patch manager doing the
> review and commit, but it also might mean contacting someone else for
> review, closing it if it¹s a duplicate, or making a won¹t-fix decision.
> It¹s the kind of activity that Allen and Steve have done a lot lately.
>
> I see the patch manager role as addressing the fact that the community
> itself has grown large and complex. As others have mentioned, it¹s not
> always clear to a new contributor who to ask for a code review. A patch
> manager would be familiar enough with the community to help steer their
> patches in the right direction.
>
> I suppose we don¹t need to formalize this too much. If anyone feels
> capable of doing this kind of queue management in a certain area of
> expertise, please dive in. Congratulations, you are now a patch manager!
> I¹m sure everyone would appreciate it.
