I agree. Lack of reviewer attention is something that is actually plaguing other OpenStack projects as well. Simply put, there is more code being proposed than we have core developer cycles to review it. But I'd rather have long wait times than a significant drop in code review quality. The most important thing is that we work as a team to identify what is most important for the project, and that those reviews get done in a timely manner. It seems like that is happening. Simultaneously, we should be encouraging each other to work on community reviews more (Salvatore's goal, I believe) as well as looking at how we can increase the number of people with deep neutron + python knowledge who can act as trusted core reviewers.
Dan On Fri, Jun 28, 2013 at 8:33 AM, Mark McClain <[email protected]>wrote: > As a team, we've ensured that priority reviews are completed on schedule > and have delivered announced features, so I'm wouldn't put us in the > relegation zone based on our current stats alone. I agree with Salvatore > that we need to publicize our review days a bit better. I also think a > bug/review is in order too (more on this in a separate email). > > Stats are a very powerful tool, but I think it is important to look behind > the numbers. The page is snapshot of the current state and the numbers do > not capture the fact we've had 4 cores (some of our most active) who've > been offline for extended periods the last month due to company changes, > family needs, and vacation. This has pushed our median a higher. > > Digging on the long reviews there are three classes: > > * A patch was proposed to spur discussion and it fails to gain consensus > from the community. > > Our oldest patch (https://review.openstack.org/#/c/17436/) clearly falls > into this category. This patch has been discussed in person and on the > mailing list, but we've yet to come up with a solution everyone embraces. > Also this patch has a higher bar because approving requires us to commit > to maintaining backwards compatibility from some time since it changes the > CLI. > > * Long response times from the proposer (one was abandoned for 60+ days). > > * Some of these are low priority patches only have one person/entity > championing the change. Being low priority items, these have fallen into a > no man's land: they are not rejected because they technically ok, but they > are not embraced because the proposer hasn't demonstrated a clear need for > change. > > mark > > > On Jun 28, 2013, at 9:12 AM, Salvatore Orlando <[email protected]> > wrote: > > Nachi, > > this wasn't a rank against missing reviews! > I hope nobody gets offended. > > My goal is to see if we can do something to improve our turnaround times. > The metric we need to improve, I think, are median time to first review > and median time to approval/abandon. > I'd prefer the median compared to the average as a metric. > > Salvatore > > > On 28 June 2013 14:54, Nachi Ueno <[email protected]> wrote: > >> Hi Salvatore >> >> Thank you for your pointing this. >> I'll improve my review counts. >> >> Best >> Nachi >> >> 2013/6/28 Salvatore Orlando <[email protected]>: >> > Not great apparently [1]. >> > If this were a soccer league among openstack projects, we would have >> been >> > relegated! >> > >> > As the things stand right now, I am part of the problem, due to lack of >> > reviews [2] >> > Even if we could all do with more reviews from the core team (barring >> the >> > ones who are already doing a great job), I reckon that the biggest >> problem >> > is the wait time for the first review. >> > A possible cause, in my opinion, lies in the review days. >> > Since each core has a specific area of expertise, patches for that area >> > might end up lying in limbo until that core's review day comes. From my >> > perspective, I am trying, as much as possible, to allocate a slice of my >> > time every day for reviews; another thing I'm doing is to pick patches >> from >> > the bottom at least one day a week to avoid starvation. >> > However, I desperately need to improve my react time to new patchsets, >> as I >> > often miss them. Gerrit emails are very high volume, so email >> notifications >> > often get lost. Suggestions are welcome. >> > >> > Another cause are plugin-specific patches. Some of these reviews, >> especially >> > for plugins with no core members, sit for a rather long time. It would >> be >> > good if every plugin sub-team lead can nominate an "alternate core dev" >> that >> > patch authors can ping for reviews. >> > >> > Salvatore >> > >> > [1] http://russellbryant.net/openstack-stats/all-openreviews.html >> > [2] http://russellbryant.net/openstack-stats/quantum-reviewers-30.txt >> > >> > -- >> > Mailing list: https://launchpad.net/~quantum-core >> > Post to : [email protected] >> > Unsubscribe : https://launchpad.net/~quantum-core >> > More help : https://help.launchpad.net/ListHelp >> > >> > > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp > > > > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
