Open Stack

I wish to highlight that the mission of Product Workgroup is to "support"
OpenStack developer community by identifying and communicating the
needs/gaps of various market/users/operators to the developers so as to
make OpenStack even better.

I think the key question is how can we highlight the priority of bug fixes
that is important to the Product WG use cases.
Would it be feasible for the Product WG core team to "short-list" the bugs
fixes and then dedicate a liason to communicate those info directly with
PTL/core reviewer.

My two cents.. :-)

Thanks!
Leong.

---

Yih Leong Sun, PhD.

Senior Software Cloud Architect.

Open Source Technology Center

Software & Services Group

Intel Corporation

yih.leong.sun at intel.com





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

> On 28 September 2015 at 18:35, Rochelle Grober <rochelle.grober at huawei.com
> >
> wrote:
>
> > Hey, guys, I'm late to this train, but I hope you appreciate my cargo;-)
> >
> > Kyle Mestery 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.
> > > >
> > > >
> > > 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.
> >
> > Kyle, we very much appreciate your comments and here, have a beer while I
> > try to calm you down....
> >
> > First, to address Armando's comment (later in this thread :-/):
> >
> > 0. The identified resources will actively participate in rapid triage of
> > bugs, and when necessary for a bug identified as high priority (or
> unknown
> > for lack of information), will attempt to collect the necessary
> information
> > to reproduce the problem and/or solve it.
> >
> > Yes, if we are not involved in the triage, nothing is going to speed up.
> > In fact, I would consider that a product or project engineer would want
> to
> > be triaging bugs almost immediately upon system entry.  The product
> > engineer should have a good enough understanding of the customers' and
> > their needs, and the developers and their needs that the engineer can
> > ensure both the priority and reproducibility (to a very large extent, but
> > they're not perfect) of the filed bug.
> >
> >
> > > > 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.
> > >
> > Where we are heading with this is:  The Product WG will identify
> corporate
> > resources who will be tasked with reviewing bug fixes when they have been
> > submitted and passed jenkins checks.  These resources will be familiar
> with
> > the code base and the OpenStack community, its processes and their
> > responsibilities.  The Product WG hopes that by decreasing the time
> before
> > first review of bug fixes, and increasing the number of critical eyes on
> > the bug fixes, it will help to speed the merge process.
> >
>
> We, as a team of contributors involved in the day-to-day management of the
> projects (aka the folks closest to the codebase) have been doing that a lot
> earlier than the Product WG ever existed. There are corporate resources who
> are already tasked with reviewing code and are familiar with the codebase
> and the processes. There's room for improvement of course, but each project
> is different and requires fine tuning that can only come from within. I am
> not sure I understand what is the value added it is intended to be proposed
> here.
>
>
> >
> > It is expected that as these extra reviewers demonstrate their skills and
> > capabilities, they will be accepted into the trust circles of the
> projects
> > and their reviews will bear enough weight to enable quicker review
> cycles.
> >
> > So, Kyle, The first pass was wish.  We, as a group, intend to work on
> this
> > until it is in a state acceptable enough by the community that discussion
> > can ensue on how to implement this.
> >
> >
> > >
> > > > 2.       These people will be added automatically as reviewers for
> > > each
> > > > bug patch submission.
> >
> > These reviewers will add the project's bugs to their watched lists so as
> > to know when a review has been submitted.
> >
> > > >
> > > > 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.
> >
> > Launchpad has the tools to be notified of bugs.  Gerrit has the tools to
> > watch projects.  A script or two could likely be written to only show
> > reviews associated with bugs.
> >
> >
> > > > 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.
> >
> > Once a patch meets the standards of a collection (specified by number of
> > devs doing priority reviews? size of project?  some way to say "well if
> xx
> > people think it's ready....) of reviewers, it is highlighted in either
> the
> > project weekly meeting or on IRC for core review attention.
> >
> > >
> > > > 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
> >
> > So, yeah, we don't want to devise a new process, we just want to improve
> > visibility to speed the existing, working but slow process.  But the key
> > here is to raise the flag to let cores know that a patch is in pretty
> good
> > shape.
> >
>
> Core reviewers talk on a daily basis and know what needs to go in and when.
> I might be missing the point of this statement.
>
>
> >
> > And, no Kyle, we don't want to usurp any developers' rights or duties or
> > impose or demand our needs be met, but we want to document a way in which
> > corporate managers can assign or direct resources specifically for bug
> > fixing and bug fix reviews (both master and stable) so as to reduce
> > backlog, improve velocity of merges, and address user issues.
>
>
> This is typically the job of the PTL/core team that knows what's important
> and can assign/direct resources specifically to where it matters. Corporate
> managers know nothing of the day to day sausage making process...now if I
> they want to get involved I am more than happy to see that happen but that
> requires a lot more than simple documentation.
>
>
> >   But, we start with a description in a language we are familiar with
> > (Arkady's proposal) and translate it into OpenStack language with the
> > correct intent.
> >
> > Does this help?
>
>
> >
> > >
> > >
> > > > 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
> >
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>