Open Stack

Hi Kyle and Armando,

Thanks for pointing out some items that require addressing.  Kyle, did you catch my reply to this proposal as well?  Would asking our cross project liaisons to raise an agenda item in the weekly project meetings and then following the normal process for review/merge address some of your concerns?

Regards,
Shamail 

> On Sep 28, 2015, at 9:16 PM, Kyle Mestery <mestery at mestery.com> wrote:
> 
>> 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
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg