Open Stack

On 28 September 2015 at 17:40, Kyle Mestery <mestery at mestery.com> wrote:

> 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.
>>
>
It seems that that a more fundamental problem is not even acknowledged
here: sometimes bug reports/fix proposal are lacking the most basic
information to get them reproduced/triaged/reviewed and that in itself can
be a very painful process to go through.

Therefore putting artificial deadlines/workflow in place is unrealistic:
what if the bug reporters/submitters disappear, what if the bug/fix
languish for other reasons?

I am not saying that we should leave this as is, but putting an artificial
process in place is not going to yield the results that you would hope. A
better solution is to educate the community members through good examples
and good practices and measuring how a project community does over time.


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