Open Stack

Kyle,
Many thanks for careful comments.
We fully understand the current process.
The goal is to put more resources to expedite the last step of bug fixing process – review and merge.
Bugs do not get the same level of attention by reviewers as new features or blueprints and spec. Thus, adding dedicated resources for bug reviews so they do not linger is the goal of this proposal.
Fixing bugs and reviews are following the standard OpenStack processes.
Sorry for not making it clearer in the proposal.
Thanks,
Arkady


From: Kyle Mestery [mailto:mestery at mestery.com]
Sent: Monday, September 28, 2015 7:41 PM
To: Kanevsky, Arkady
Cc: product-wg at lists.openstack.org; Armando Migliaccio
Subject: Re: [Product] proposal for expediting bug fixes

On Mon, Sep 28, 2015 at 5:03 PM, <Arkady_Kanevsky at dell.com<mailto: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<mailto:Product-wg at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg