Open Stack

On Mon, Sep 28, 2015 at 5:03 PM, <Arkady_Kanevsky at dell.com> wrote:

> Problem: Currently bug fixes take a long time especially for previous
> releases.
>
>
This proposal has multiple problems which I'll address below. But the
biggest issue is it appears to try and "anoint" people into a certain role.
This goes against Open Source philosophies, you have to show up and do the
legwork to get that sort of recognition. You can't force this onto project
teams. See below for specific issues with this proposal.


> Proposal:
>
> 1.       For each project Product WG identify a couple of people ( at
> least 3 overall to handle vacations and a like) among its member companies
> who will have responsibility to review submitted bug fixes (for all
> releases) within 1 day
>
>
Are you saying that for each code submission for a bug fix, you want these
people to review the code within one day? What type of review? And if it's
a simple +1 review, it won't be helpful. There is no timetable for how long
a bug takes to land, the code review is only part of the process. The
submitter has to iterate, the gate has to digest the change, etc.



> 2.       These people will be added automatically as reviewers for each
> bug patch submission.
>
> a.       Need some help with tool people to automatically add these people
> as reviewers for newly filed bugs
>
>
Why do you want to automatically add people to these reviews? We have
gerrit dashboards which they can use to do this themselves.


> 3.       Once a patch has two +1 ones from these reviewers and no -1s from
> anybody else, project PTL or project designated bug tsar will merge it if
> it passes his/her review within 2 days
>
>
This ain't gonna happen. This is not how code is merged in OpenStack. If
this is a stable backport, we have a stable review team which does this
already [1]. If it's for master, it's even more insane to think PTLs will
merge code with +1s from some folks. The process for merging code is
documented here [2], I encourage you to read that and understand it in
detail.


> a.       Need to agree on the mechanism to let PTL or designate know of
> patch readiness. Maybe one of the reviewers adds PTL or designate to the
> patch when passing baton criteria is met. (Best to run by PTLs and TC for
> recommendation).
>
>
It sounds to me like you're basically doing an end-run around the current
stable team [1]. Can you explain why the current stable review process
isn't enough for your needs? Now, if I've mistaken this and you expect this
behavior for master branch changes, then forgive me, but this again goes
against the current workflow for merging patches each project has.

[1] http://docs.openstack.org/project-team-guide/stable-branches.html
[2] http://docs.openstack.org/infra/manual/developers.html


> 4.       Have periodic bug scrub per project (weekly? Monthly?) and choose
> small # of bugs to tackle for this period.
>
> 5.       Once we, Product WG, agree on the proposal, Rocky will present it
> to PTL on cross functional meeting.
>
>
Before you present this to anyone else, I'd encourage you to first
understand if you're talking about stable or master branches here. And
either way, trying to end-run the process to force this type of thing on
projects isn't going to be received warmly. I suggest you look at the
existing process for merging code for bugs (in both master and stable) and
work with the teams to improve those rather than trying to do what you're
proposing above. That would be more helpful to the project teams than
mandating something like this.

Thanks,
Kyle


> Comments please.
>
> Arkady Kanevsky, Ph.D.
> Director of SW Development
> Dell ESG
> Dell Inc. One Dell Way, MS PS2-91
> Round Rock, TX 78682, USA
> Phone: 512 723 5264
>
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>