Open Stack

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

> Kyle,
>
> To be precise of anecdotal data, every developer knows the milestones for
> current master work. But there is no “deadline” for bugs.
>
> But fixing any bug in the release before last is not supported and only
> security patches are considered. While one can work with their distro
> partner if they get OpenSource from to get patch merged or work with
> Customer but having patch more widely available for the community is much
> harder.
>
>
>
Arkady, I'd encourage you to thoroughly review the stable wiki page [1],
because you're simply not stating anything close to what's documented. Bugs
are encouraged to be backported to stable branches. Bugs cannot be fixed
directly in stable branches (there is a grey zone here for things which may
have been deprecated, etc.), but must be checked into master and
cherry-picked back to stable. It's just not true to say bug fixes are not
supported in stable branches and only security patches are.

My gut says what you're really concerned about here is older releases which
upstream no longer supports. If that's the case, we should discuss this
with the broader community, and specifically those who work on stable
branches. This usually gets discussed at each summit as well.


> It would be interesting to run analytics on git to see how long it takes
> to review and merge bugs on released branches vs master development patches.
>

It would, and my gut says it's MUCH faster on stable branches because those
patches are simply cherry picks for the most part and the review consists
of ensuring the patch has landed in master. and meets the guidelines found
here [1]. Master reviews are much more harsh, as that's the patch is
iterated on to get into a shape it can be merged in the first place.

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/StableBranch

Thanks again,
>
> Arkady
>
>
>
> *From:* Kanevsky, Arkady
> *Sent:* Tuesday, September 29, 2015 1:20 PM
> *To:* 'Kyle Mestery'
> *Cc:* product-wg at lists.openstack.org; Armando Migliaccio
> *Subject:* RE: [Product] proposal for expediting bug fixes
>
>
>
> Kyle,
>
> I do not have any data for Neutron.
>
> My anecdotal data is based on Nova and Cinder.
>
>
>
> Will update the proposal and position it as augmentation of current
> process rather than standalone one.
>
> Thanks,
>
> Arkady
>
>
>
> *From:* Kyle Mestery [mailto:mestery at mestery.com <mestery at mestery.com>]
> *Sent:* Tuesday, September 29, 2015 1:17 PM
>
> *To:* Kanevsky, Arkady
> *Cc:* product-wg at lists.openstack.org; Armando Migliaccio
> *Subject:* Re: [Product] proposal for expediting bug fixes
>
>
>
> 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
>
>
>
>
>