openbmc bug management

Khetan, Sharad sharad.khetan at intel.com
Tue Aug 21 05:15:50 AEST 2018


My 2 cents:

I also think the defects have to be filed on a repository basis. While it shouldn’t be necessary for the submitter to already contribute to community before filing a defect, it is reasonable to expect that the submitter has taken some time to familiarize herself with the overall rep organization and has done the due diligence in picking the right repository. After that, it will really be up to maintainers or other active developers on that repo to take action - and move as necessary. We will need guidelines on how to file defects that span multiple repositories. And we will likely still need a catchall miscellaneous defect category for defects that have no clear repo (or submitter could not pick, or maintainers could not decide...). Having a "how to file defects" document and providing initial guidance will be useful. I think it's early to talk about SLA and metrics at this point. Let's get the filing mostly sorted out first.

Thanks,
-Sharad


-----Original Message-----
From: openbmc [mailto:openbmc-bounces+sharad.khetan=intel.com at lists.ozlabs.org] On Behalf Of Patrick Venture
Sent: Monday, August 20, 2018 11:15 AM
To: Sivas Srr <sivas.srr at in.ibm.com>
Cc: anoo at linux.vnet.ibm.com; OpenBMC Maillist <openbmc at lists.ozlabs.org>
Subject: Re: openbmc bug management

On Mon, Aug 13, 2018 at 9:40 AM Sivas Srr <sivas.srr at in.ibm.com> wrote:
>
> Good discussion topic, Andrew.
>
> My thoughts:
> ==========
>
> First of all, bug should be associate with SLA/some kind of metrics on how quickly it gets resolved.
>
> Bug submitter is already started donating/contributing to the community by pointing the issue in the code,
> when bug submitter opens an issue.
>
> It is the maintainer (other assigned person) responsibility to accept (fix the bug) or prove it is not in their
> area and pointed out the issue/bug to the other repository with details.  (From the horse's mouth)
>
> If the ownership of moving/closing bug to the submitter, I feel the point of isolating the bug may not happen accurately.
>
> Second point (back to SLA), If the submitter owns it then SLA/Metrics may not be accurate. This will be totally different than what normally industry follows, I guess.
>
> Real Life Scenario:
> ===============
> For eg. if person A points out issue/bug in person B shirt, Can person A responsible to change person B shirt?
>
>
>
> Sivas R. S
> E-mail: sivas.srr at in.ibm.com
> E2E FSP Test Architecture, OpenBMC Test Lead, Lab Management
> Automation is good, Identifying Defect earlier is better always
> 9902233500
> 08046678273
>
>
>
> ----- Original message -----
> From: Andrew Geissler <geissonator at gmail.com>
> Sent by: "openbmc" <openbmc-bounces+sivas.srr=in.ibm.com at lists.ozlabs.org>
> To: Adriana Kobylak <anoo at linux.vnet.ibm.com>, OpenBMC Maillist <openbmc at lists.ozlabs.org>
> Cc:
> Subject: openbmc bug management
> Date: Mon, Aug 13, 2018 9:34 PM
>
> Currently we mostly open bugs against openbmc/openbmc.  This is nice
> in that it provides a single location to search for all bugs related
> to openbmc, but it doesn't provide any clear ownership for someone to
> drive the bug, and it becomes more and more unmanageable as the
> openbmc project continues to grow.
>
> Per the community call topic today, we'd like to start having bugs
> assigned to the specific repo that will provide the fix to the bug.
> The main concern with this is that if someone is unsure on where the
> bug should go and takes a best guess, if the guess is wrong, how do we
> ensure the bug gets routed correctly?  The idea was that it's the
> responsibility of the creator of the bug, so the repo owner says
> something to the affect of "not my problem" (with some guidance on
> who's it is if they know) and the bug submitter will then use the
> zenhub option "Move Issue" to close it in the current repo and copy it
> over to the new repo.
>
> Thoughts or concerns?

I think it's completely reasonable to expect maintainers to watch
their incoming bugs and redirect as necessary.  Furthermore, I think
it is too much to have all the bugs filed into one project.  I know
that I never check it for new bugs there because of this.

Those are my $0.02.

> Andrew
>
>
>


More information about the openbmc mailing list