Open Stack

Thanks Jay. I agree with your position on it, and that is exactly what I
would expect as the process in a collaborative community. That "feels like
the right way" ;-)

Unfortunately, there have been situations where we have had to ask a
reviewer multiple times to re-review the code (after issues identified in a
previous review have been addressed). Then you struggle between "am I
pestering the reviewer" vs. "what more can we do/needs to be done, please
help us understand" - and absence of that feedback leads to discouragement
for new contributors and piling up of patches for the big deluge near the
cut-off deadlines. My suggestion was to deal with outliers like that.

If there was a clear guideline, that facilitated the smooth flow of patches
and an automated reminder that did not make the person asking for reviews
feel that he/she is pestering, that might help. Or maybe if we update infra
to report on avg. number of days that a negative review was not re-reviewed
after a new patch, we could just address the outliers when we see them.
Just an idea to address the outliers, not the normal flow.

Regards,
Mandeep
-----



On Sat, Jul 26, 2014 at 10:19 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 07/25/2014 05:48 PM, Mandeep Dhami 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?
>>
>
> Guilty as charged, Mandeep. :( If I have failed to re-review something in
> a timely manner, please don't hesitate to either find me on IRC or send me
> an email saying "hey, don't forget about XYZ". People get behind on reviews
> and sometimes things slip the mind. A gentle reminder is all that is
> needed, usually.
>
> As for a hard number of days before sending an email notification, that
> might be possible, but it's not like we all have our vacation reminders
> linked in to Gerrit ;) I think a more personal email or IRC request for
> specific reviews is more appropriate.
>
> Best,
> -jay
>
>  On Fri, Jul 25, 2014 at 12:50 PM, Steve Gordon <sgordon at redhat.com
>> <mailto:sgordon at redhat.com>> wrote:
>>
>>     ----- Original Message -----
>>      > From: "Jay Pipes" <jaypipes at gmail.com <mailto:jaypipes at gmail.com>>
>>      > To: openstack-dev at lists.openstack.org
>>     <mailto: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
>>     <mailto: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/20140726/2149b2c3/attachment.html>