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 <sgor...@redhat.com
<mailto:sgor...@redhat.com>> wrote:
----- Original Message -----
> From: "Jay Pipes" <jaypi...@gmail.com <mailto:jaypi...@gmail.com>>
> To: openstack-dev@lists.openstack.org
<mailto:openstack-dev@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev