Open Stack

On Mon, Sep 28, 2015 at 8:04 PM, Armando M. <armamig at gmail.com> wrote:

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

I agree 100% with you here. But I don't want you to miss the point where
the proposal appears to mandate and anoint a section of people who will
effectively be allowed to bless code going in, while completely ignoring
the fact we have such a system in place (they're called core reviewers). To
me, this is the most egregious oversight of this proposal.


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