Open Stack

On Tue, Sep 29, 2015 at 1:08 PM, <Arkady_Kanevsky at dell.com> wrote:

> 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.
>

Can you point me to the data you've gathered to support this? I'm curious
to see this. Because as near as I can tell, in Neutron we closed 500+ bugs
in Liberty and only implemented < 30 BPs. So the data to me says bugs get
much more attention than features.

Fixing bugs and reviews are following the standard OpenStack processes.
>

I think you should update your proposal to indicate this then rather than
trying to come up with a new process.


> Sorry for not making it clearer in the proposal.
>

No worries, I'm happy to help.

Thanks,
Kyle

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> 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
>
>
>