Ihar,
Thanks for the nomination, I'll just chime-in below.
On 05/19/2016 03:13 PM, Ihar Hrachyshka wrote:
On 19 May 2016, at 13:18, Tony Breeds <t...@bakeyournoodle.com> wrote:
On Thu, May 19, 2016 at 10:49:26AM +0200, Ihar Hrachyshka wrote:
On 19 May 2016, at 02:12, Tony Breeds <t...@bakeyournoodle.com> wrote:
On Tue, May 17, 2016 at 01:07:48PM +0200, Ihar Hrachyshka wrote:
Hi stable-maint-core and all,
I would like to propose Brian for neutron specific stable team.
+1
It'd be nice to see some comments on the reviews to indicate that the various
aspects of the policy have been thought about.
I know it gets a little repetitive but it's hard to assess the quality of
reviews without it :/
Meh. I am not sure we want to follow the rabbit into the deep hole.
Fair enough. We can agree to disagree ;P
My problem with reviewing specific comments is that we never made it a
requirement for nominations into other core teams. (When I was nominated to
neutron-core, no one validated my specific comments; instead votes were based
on general perception of my contributions.)
If we think it should be a requirement for stable maintainers, we may make it
explicit in our stable policies, and then we may enforce it. [Not that I agree
with such a requirement...]
I'll admit I typically haven't been judging stable backports from a policy
perspective, I'm typically looking at them from the other end - now that we
fixed this in master, is this broken in stable/foo and should it be backported?
And how far? And does it make sense? Basically, changing from a reactive to
a proactive model.
I know most of the stable rules, and when I don't know what to do I usually just
ask Ihar ;)
I say, people working with the person in question are in the best position to
judge. If you don’t pay attention to neutron branches (rightfully so!),
obviously it’s hard to assess.
Of course. I agree with you.
That’s why we should have some sense of delegation in our stable team
hierarchy (stable-maint-core doing initial sanity checks, details left up to
project specific teams).
You say "should" here, which confuses me a little as I thought that's exactly
what we did. Where do you feel like we should delegate, that we aren't?
We do delegate.
I only suggested that it’s hard for stable-maint-core to assess candidate
involvement in project specific stable matters, hence we should generally trust
choices made by project teams, as long as they pass basic sanity checks.
Getting into too much detail, like checking candidate’s comments in gerrit,
does seem like too much to me. Though basic validation that the person have a
significant history of prior reviews does seem like a reasonable job for
stable-maint-core though.
Stable releases are still supervised by stable PTL and liaisons, and are done
in gerrit, where any issues with policy violations can be discussed, and where
violators may be held responsible. If stable-maint-core will have problems with
some candidates, we can always revoke permissions.
I'm part of the DVR sub-team in Neutron, so most of my focus is there, and it's
been a pretty hot spot in the stable releases as people start to deploy it more.
I agreed to the nomination so I could be delegated in that little corner and
expand from there, much as I did with upstream Neutron. My goal is to increase
the speed at which the downstream users (distros) can consume the stable
branches and get fixes to their customers.
-Brian
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
