Open Stack

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
>