Open Stack

I agree that it's important to set a guideline for this topic.
What if the said reviewer is "on vacation or indisposed"? Should a fallback
strategy exist for that case? A reviewer could indicate a "delegate core"
to review its -2s whenever he has no chance to do it.

Thanks,
Ivar.


On Fri, Jul 25, 2014 at 5:35 PM, Mandeep Dhami <dhami at noironetworks.com>
wrote:

>
> What would be a good guideline for "timely manner"? I would recommend
> something like 2-3 days unless the reviewer is on vacation or is
> indisposed. Is it possible to update gerrit/jenkins to send reminders to
> reviewers in such a scenario?
>
> Regards,
> Mandeep
> -----
>
>
>
>
> On Fri, Jul 25, 2014 at 3:14 PM, Kyle Mestery <mestery at mestery.com> wrote:
>
>> On Fri, Jul 25, 2014 at 4:48 PM, Mandeep Dhami <dhami at noironetworks.com>
>> wrote:
>> >
>> > Thanks for the deck Jay, that is very helpful.
>> >
>> > Also, would it help the process by having some clear
>> guidelines/expectations
>> > around review time as well? In particular, if you have put a -1 or -2,
>> and
>> > the issues that you have identified have been addressed by an update
>> (or at
>> > least the original author thinks that he has addressed your concern),
>> is it
>> > reasonable to expect that you will re-review in a "reasonable time"?
>> This
>> > way, the updates can either proceed, or be rejected, as they are being
>> > developed instead of accumulating in a backlog that we then try to get
>> > approved on the last day of the cut-off?
>> >
>> I agree, if someone puts a -2 on a patch stressing an issue and the
>> committer has resolved those issues, the -2 should also be resolved in
>> a timely manner. If the issue can't be resolved in the review itself,
>> as this wiki page [1] indicates, the issue should be moved to the
>> mailing list.
>>
>> Thanks,
>> Kyle
>>
>> [1] https://wiki.openstack.org/wiki/CodeReviewGuidelines
>>
>> > Regards,
>> > Mandeep
>> >
>> >
>> >
>> > On Fri, Jul 25, 2014 at 12:50 PM, Steve Gordon <sgordon at redhat.com>
>> wrote:
>> >>
>> >> ----- Original Message -----
>> >> > From: "Jay Pipes" <jaypipes at gmail.com>
>> >> > To: openstack-dev at lists.openstack.org
>> >> >
>> >> > On 07/24/2014 10:05 AM, CARVER, PAUL wrote:
>> >> > > Alan Kavanagh wrote:
>> >> > >
>> >> > >> If we have more work being put on the table, then more Core
>> >> > >> members would definitely go a long way with assisting this, we
>> cant
>> >> > >> wait for folks to be reviewing stuff as an excuse to not get
>> >> > >> features landed in a given release.
>> >> >
>> >> > We absolutely can and should wait for folks to be reviewing stuff
>> >> > properly. A large number of problems in OpenStack code and flawed
>> design
>> >> > can be attributed to impatience and pushing through code that wasn't
>> >> > ready.
>> >> >
>> >> > I've said this many times, but the best way to get core reviews on
>> >> > patches that you submit is to put the effort into reviewing others'
>> >> > code. Core reviewers are more willing to do reviews for someone who
>> is
>> >> > clearly trying to help the project in more ways than just pushing
>> their
>> >> > own code. Note that, Alan, I'm not trying to imply that you are
>> guilty
>> >> > of the above! :) I'm just recommending techniques for the general
>> >> > contributor community who are not on a core team (including myself!).
>> >>
>> >> I agree with all of the above, I do think however there is another
>> >> un-addressed area where there *may* be room for optimization - which
>> is how
>> >> we use the earlier milestones. I apologize in advance because this is
>> >> somewhat tangential to Alan's points but I think it is relevant to the
>> >> general frustration around what did/didn't get approved in time for the
>> >> deadline and ultimately what will or wont get reviewed in time to make
>> the
>> >> release versus being punted to Kilo or even further down the road.
>> >>
>> >> We land very, very, little in terms of feature work in the *-1 and *-2
>> >> milestones in each release (and this is not just a Neutron thing). Even
>> >> though we know without a doubt that the amount of work currently
>> approved
>> >> for J-3 is not realistic we also know that we will land significantly
>> more
>> >> features in this milestone than the other two that have already been
>> and
>> >> gone, which to my way of thinking is actually kind of backwards to the
>> ideal
>> >> situation.
>> >>
>> >> What is unclear to me however is how much of this is a result of
>> >> difficulty identifying and approving less controversial/more
>> straightforward
>> >> specifications quickly following summit (keeping in mind this time
>> around
>> >> there was arguably some additional delay as the *-specs repository
>> approach
>> >> was bedded down), an unavoidable result of human nature being to
>> *really*
>> >> push when there is a *hard* deadline to beat, or just that these
>> earlier
>> >> milestones are somewhat impacted from fatigue from the summit (I know
>> a lot
>> >> of people also try to take some well earned time off around this
>> period + of
>> >> course many are still concentrated on stabilization of the previous
>> >> release). As a result it's unclear whether there is anything concrete
>> that
>> >> can be done to change this but I thought I would bring it up in case
>> anyone
>> >> else has any bright ideas!
>> >>
>> >> > [SNIP]
>> >>
>> >> > > We ought to (in my personal opinion) be supplying core reviewers to
>> >> > > at least a couple of OpenStack projects. But one way or another we
>> >> > > need to get more capabilities reviewed and merged. My personal top
>> >> > > disappointments are with the current state of IPv6, HA, and QoS,
>> but
>> >> > > I'm sure other folks can list lots of other capabilities that
>> >> > > they're really going to be frustrated to find lacking in Juno.
>> >> >
>> >> > I agree with you. It's not something that is fixable overnight, or
>> by a
>> >> > small group of people, IMO. It's something that needs to be
>> addressed by
>> >> > the core project teams, acting as a group in order to reduce review
>> wait
>> >> > times and ensure that there is responsiveness, transparency and
>> >> > thoroughness to the review (code as well as spec) process.
>> >> >
>> >> > I put together some slides recently that have some insights and
>> >> > (hopefully) some helpful suggestions for both doing and receiving
>> code
>> >> > reviews, as well as staying sane in the era of corporate agendas.
>> >> > Perhaps folks will find it useful:
>> >> >
>> >> > http://bit.ly/navigating-openstack-community
>> >>
>> >> As an aside this is a very well put together deck, thanks for sharing!
>> >>
>> >> -Steve
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140725/235f6431/attachment.html>