Re: Patch review process

On Wed, Feb 11, 2015 at 2:04 PM, Steve Loughran wrote: > 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 > someon

Re: Patch review process

On 11 February 2015 at 21:11:25, Chris Douglas (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 m

Re: Patch review process

+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 mo

Re: Patch review process

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 m

Re: Patch review process

> How could we speed up? +1 for trying Crucible. We should try whether it's integrated well and it can solve the problem of "splitting discussion". If Crucible solves it, it would be great. About the patch manager, I concern that it can delay reviews if the patch size is too small and the amount

Re: Patch review process

On 9 February 2015 at 21:18:52, Colin P. McCabe (cmcc...@apache.org) wrote: What happened with the Crucible experiment? Did we get a chance to try that out? That would be a great way to speed up patch reviews, and one that is well-integrated with JIRA. I am -1 on Ge

Re: Patch review process

What happened with the Crucible experiment? Did we get a chance to try that out? That would be a great way to speed up patch reviews, and one that is well-integrated with JIRA. I am -1 on Gerrit unless we can find a way to mirror the comments to JIRA. I think splitting the discussion is a far w

Re: Patch review process

On 8 February 2015 at 09:55:42, Karthik Kambatla (ka...@cloudera.com) wrote: On Fri, Feb 6, 2015 at 6:14 PM, Colin P. McCabe wrote: > I think it's healthy to have lots of JIRAs that are "patch available." > It means that there is a lot of interest in the project an

Re: Patch review process

On Fri, Feb 6, 2015 at 6:14 PM, Colin P. McCabe wrote: > I think it's healthy to have lots of JIRAs that are "patch available." > It means that there is a lot of interest in the project and people > want to contribute. It would be unhealthy if JIRAs that really needed > to get in were not getti

Re: Patch review process

On 7 February 2015 at 02:14:39, Colin P. McCabe (cmcc...@apache.org) wrote: I think it's healthy to have lots of JIRAs that are "patch available." It means that there is a lot of interest in the project and people want to contribute. It would be unhealthy if JIRAs that r

Re: Patch review process

I think it's healthy to have lots of JIRAs that are "patch available." It means that there is a lot of interest in the project and people want to contribute. It would be unhealthy if JIRAs that really needed to get in were not getting in. But beyond a few horror stories, that usually doesn't see

Re: Patch review process

I'm thinking it's unhealthy to have over 1000 JIRAs patch available. Reviewers should be more welcome and should review patches from everywhere to increase developers and future reviewers. I'm not completely sure patch managers will make it healthy, however, changing the process (and this disc

Re: Patch review process

+1 to patch managers per component. On Wed, Feb 4, 2015 at 12:29 PM, Allen Wittenauer wrote: > > Is process really the problem? Or, more directly, how does any of > this actually increase the pool beyond the (I’m feeling generous today) 10 > or so committers (never mind PMC) that actua

Re: Patch review process

There are many ways to find reviewers. Look at the set of watchers, email people who work on that component (check git if you're unsure who's been there recently), or even email random committers and ask for leads. Privately ask people why they stopped responding to an issue. Even if an issue has a

Re: Patch review process

Is process really the problem? Or, more directly, how does any of this actually increase the pool beyond the (I’m feeling generous today) 10 or so committers (never mind PMC) that actually review patches that come from outside their employers on a regular basis? To put this in

Re: Patch review process

Release managers are just committers trying to roll releases; it's not an enduring role. A patch manager is just someone helping to track work and direct reviewers to issues. The job doesn't come with a hat. We could look into a badge and gun if that would help. This doesn't require a lot of hand-

Re: Patch review process

The main JIRA dashboard for each project has an Issues tab with useful summary statistics and links to filtered queries, most notably links to unresolved issues grouped by each project sub-component. https://issues.apache.org/jira/browse/HADOOP/?selectedTab=com.atlassian.jir a.jira-projects-plugin

Re: Patch review process

I'm worrying more about the ongoing situation. As a release approaches someone effectively goes full time as the gatekeeper, -for a good release they should be saying "too late!" for most features and "only if it's low risk" to non-critical bug fixes Which means that non-critical stuff don't g

Re: Patch review process

I wonder if this work logically falls under the release manager role. During a release, we generally spend a little bit of time thinking about what new features we added, systems we stabilized, interfaces we changed, etc. etc. This gives us some perspective to look backwards at old JIRAs and eith

Re: Patch review process

+1 on the idea of patch managers. As the patch managers should have good expertise on the specific fields, they are more productive on reviewing the patches and driving the development on the specific fields forward. ~Haohui On Mon, Feb 2, 2015 at 12:55 PM, Chris Nauroth wrote: > I like the ide

Re: Patch review process

I like the idea of patch managers monitoring specific queues of issues, perhaps implemented as a set of jira filters on different values for the component or label fields. Right now, looking at the whole HADOOP backlog is daunting. Using separate filtered review queues could help each reviewer fo

Re: Patch review process

Many projects have unofficial "patch managers": http://producingoss.com/en/share-management.html#patch-manager People who go through outstanding issues, ensuring that each has reached a stable state, or at least a willing reviewer. -C On Mon, Feb 2, 2015 at 3:45 AM, Steve Loughran wrote: > > Gi

Re: Patch review process

Given experience of apache reviews, I don't know how much time to spend on it. I'm curious about Gerrit, but again, if JIRA integration is what is sought, Cruicible sounds better. Returning to other issues in the discussion 1. Improving test times would make a big difference; locally as well a

Re: Patch review process

chanics >>>>> of >>>>>> committing can take longer than reviewing the patch. >>>>>> - There were also concerns about forking discussions between JIRA >> and >>>>>> Gerrit. This has been an issue in Spark, and we'd like to k

Re: Patch review process

talk about how to improve precommit. Right now it takes > hours to > >> > run > >> > > the unit tests, which slows down patch iterations. One solution is > >> > running > >> > > tests in parallel (and even distributed). Previous distributed >

Re: Patch review process

>> > > amount of work to actually make this production ready. >> > > - Also mention of putting in place more linting and static analysis. >> > > Automating this will save reviewer time. >> > > >> > > Best, >> > > Andrew >> > &g

Re: Patch review process

> > Andrew, can the community build on your distributed pre-commit work to make > it production ready? > > I'm happy to share it if someone is willing to take it across the finish line. I think it'd be about two weeks of work full-time. I've already cleaned it up some, but it still requires checkin

Re: Patch review process

s > > > > have done a full unit test run in a couple minutes, but it'd be a > fair > > > > amount of work to actually make this production ready. > > > > - Also mention of putting in place more linting and static analysis. > > > > Autom

Re: Patch review process

Also mention of putting in place more linting and static analysis. > > > Automating this will save reviewer time. > > > > > > Best, > > > Andrew > > > > > > On Mon, Jan 26, 2015 at 9:16 AM, Ted Yu wrote: > > > > > > > In some cases, c

Re: Patch review process

it takes > hours > > to > > > > run > > > > > the unit tests, which slows down patch iterations. One solution is > > > > running > > > > > tests in parallel (and even distributed). Previous distributed > > > > experim

Re: Patch review process

t; > experiments > > > > have done a full unit test run in a couple minutes, but it'd be a > fair > > > > amount of work to actually make this production ready. > > > > - Also mention of putting in place more linting and static analysis. &g

Re: Patch review process

wrote: > > > > > > > In some cases, contributor responded to review comments and attached > > > > patches addressing the comments. > > > > > > > > Later on, there was simply no response to the latest patch - even > with > > > > f

Re: Patch review process

:16 AM, Ted Yu wrote: > > > > > > > In some cases, contributor responded to review comments and attached > > > > patches addressing the comments. > > > > > > > > Later on, there was simply no response to the latest patch - even > with > >

Re: Patch review process

> In some cases, contributor responded to review comments and attached > > > patches addressing the comments. > > > > > > Later on, there was simply no response to the latest patch - even with > > > follow-on ping. > > > > > > I wish this a

Re: Patch review process

gt; > > > Cheers > > > > On Sun, Jan 25, 2015 at 6:03 PM, Tsz Wo (Nicholas), Sze < > > s29752-hadoopgene...@yahoo.com.invalid> wrote: > > > > > Hi contributors, > > > I would like to (re)start a discussion regrading to our patch review &

Re: Patch review process

s. > > > > Later on, there was simply no response to the latest patch - even with > > follow-on ping. > > > > I wish this aspect can be improved. > > > > Cheers > > > > On Sun, Jan 25, 2015 at 6:03 PM, Tsz Wo (Nicholas), Sze < > > s297

Re: Patch review process

d. > > Cheers > > On Sun, Jan 25, 2015 at 6:03 PM, Tsz Wo (Nicholas), Sze < > s29752-hadoopgene...@yahoo.com.invalid> wrote: > > > Hi contributors, > > I would like to (re)start a discussion regrading to our patch review > > process. A similar discussion