Hi Dan, Mark I agree with you guys.
PS: Sorry, I was wrong. Russels code looks OK for many cases. We can use his code for checking long-waiting patch 2013/6/28 Dan Wendlandt <[email protected]>: > 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 > -- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
