ubuntu-bugcontrol team mailing list archive

[Frank Heimes <frank.heimes@xxxxxxxxxxxxx>]

Hi Brian et al,

There are several aspects that would result from a 'Ubuntu Bug Control'
membership.

* Even if I mainly work on two special projects that are related to the
s390x and the ppc64el architectures, several bugs that I work on / manage /
triage are architecture agnostic. Hence Ubuntu Server in general will
benefit from the work I do on LP bugs.
* In addition I need to work closely together with further developers and
package maintainers, therefore it's often the case that multiple parties,
releases and projects are involved in a single bug.
But today I cannot optimally triage or manage such kinds of tickets,
because of my limited permission. I can for example adjust the status and
important of the projects that affects a bug and that I am a member of, but
I can only barely modify the status of a package (just as an example).
As a workaround I need to ask (well, bother) fellow colleagues to change or
adjust certain fields in LP - which is a waste of time for the fellows and
for me.
So another aspect will be an increase of efficiency - not only for me.
* Becoming more efficient would at the end allow me to process more bugs in
the same amount of time, which would result in an increased throughput. It
will help me doing my job in a better way.
* In my role as tech. lead for Ubuntu on IBM Z (s390x) I'm already doing
bi-weekly bug scrub sessions (in a smaller group of up to 5 people) and
these would just become more straight-forward.
I'm leading the s390x LP bug triage sessions, but also participate the
ppc64el LP bug triage sessions.
* I think/hope that my communication is honest, diplomatic and tactful, but
sometimes also firm.
* In case more background information or error reports (apport, but also
arch-specific reports like 'dbginfo') are needed, I ask for these to
improve the decision making and triage process.
In the past that often led to adjustments in the bug title, description,
affected packages or assignees, or even helped to identify duplicate bugs.
* In several situations I also forwarded or helped to forward bugs to
upstream (Like pertest on Mellanox git, s390s-specific tools at IBM
developerWorks or nowadays s390-tools git).
* With my background on s390x (and ppc64el) I may bring in some special
knowledge to the team.

I hope that these aspects fit to requirements for a Ubuntu Bug Squad
membership.

Thx, Frank

Frank Heimes | Tech. Lead Ubuntu Server on Z | Canonical Ltd.
mail: frank.heimes@xxxxxxxxxxxxx
irc: jfh
www.canonical.com | www.ubuntu.com | ubuntu-on-big-iron.blogspot.com
<http://ubuntu-on-big-iron.blogspot.com/?view=sidebar>

On Tue, Jan 2, 2018 at 9:18 PM, Brian Murray <brian@xxxxxxxxxxxxx> wrote:

> The application process asks that you indicate what importance you would
> give and explain the reasoning the bug report since that is a new
> ability that you would have.
>
> Thanks!
>
> Brian
>
> On Wed, Dec 13, 2017 at 09:47:57PM +0100, Frank Heimes wrote:
> > Hi,
> > so I have a list of 10 examples.
> >
> > These are probably not absolute perfect ones, but show the variety and
> > differences:
> >
> >
> > this was a really long running bug ticket.
> > It was even opened before I joined Canonical and at some point in time I
> > took it over from dannf.
> > I needed to push Mellanox for more than 6 month to create an upstream for
> > for that issue.
> > Once it became officially availabel xnox was also to update our package
> > based on the latest Mellanox code and I did some final verifications.
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1553185
> >
> > the massive updates on the Mellanox rdma and ib stack fortunately helps
> to
> > tacke other related tickets like this:
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1553183
> > this is till not yet fix released because the guy (from IBM) who
> originally
> > openend that ticket was not yet able to verify it
> > (but I verified it on one of our systems)
> >
> > the next one is an example about what we usually don't do that often -
> > package upgrade with an buntu release
> > but this time it was required and desired by different parties
> > I worked behind the scenes on that with mwhudson - it was quite complex
> due
> > to lot's of dependencies
> > at the end I again did the final verification
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1637223
> >
> > sometimes I for sure also open tickets by myself and work on closing them
> > this bug was caused by a quite little issue:
> > IBM dropped an argument from an architecture specific tool (without
> > mentioning this in the changelog) that is used by d-i
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1718463
> >
> > sometimes our hardware certification team is running into an issue that I
> > work on
> > in this example I found after having a look at the logs that the issue is
> > due to our (at that time) outdated zVM hypervisor
> > I updated it and applied a patch on top and we verified that the problem
> > got solved (this time reported by xnox)
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1666679
> >
> > this is an example of regression (in the docker space), with multiple
> > releases involved:
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1658009
> >
> > this is a totally different example, it's about the lack of the container
> > live migration feature on the s390x platform
> > I opened that ticket in LP, but then synched over to IBM, because IBM is
> > responsible for any base enablement and porting of tools for the s390x
> > (process fr that is described in my GoogleDoc mentioned before) platform,
> > IBM team completed the porting over time and brought the needed patches
> > upstream
> > and in between we have CRIU for s390x starting with 17.10 as the first
> > Linux distro
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1635845
> >
> > this kpatch-build ticket is similar - IBM needs to work on that (and
> still
> > does)
> > before we may think about offering kernel live-patch for the s390x
> > platform, too:
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1639924
> >
> > I'm also passing over ticket reported by other (like our testers) to IBM
> -
> > see these two examples of minor issues:
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1633513
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1616590
> >
> > an example where I reported a (non critical) issue that is unfortunately
> > hard to solve
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1704929
> > we still have no idea how to solve that (how to get rid of these msgs) -
> > for now we at least tracked it down to a kernel problem
> > and because this is probably arch specific we looking at it jointly with
> > IBM ...
> >
> > another example where I only somehow managed the ticket - with several
> > parties and Ubuntu releases involved
> > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1595192
> >
> > Please keep in mind that I needed to ask a colleague from time to time in
> > the past to assign tasks to the right parties and people,
> > just because I don't have the needed permissions in LP I am applying
> for.
> >
> >
> > Bye, Frank
> >
> >
> >
> > Frank Heimes | Tech. Lead Ubuntu Server on Z | Canonical Ltd.
> > mail: frank.heimes@xxxxxxxxxxxxx
> > irc: jfh
> > www.canonical.com | www.ubuntu.com | ubuntu-on-big-iron.blogspot.com
> > <http://ubuntu-on-big-iron.blogspot.com/?view=sidebar> |
> > http://fridge.ubuntu.com
> >
> > On Wed, Dec 13, 2017 at 8:28 PM, Brian Murray <brian@xxxxxxxxxxxxx>
> wrote:
> >
> > > On Wed, Dec 13, 2017 at 03:21:12PM +0100, Frank Heimes wrote:
> > > > Thanks Vej !
> > > >
> > > > Hi Brian, looks like I always end up with you    :-)
> > > >
> > > > Since I don't expect that my job and role changes soon, I think
> getting
> > > > access granted as an employee of Canonical is probably not bad.
> > > >
> > > > But anyway, I'm happy to officially apply as an individual:
> > > >
> > > > I've already signed the ubuntu code of conduct and have already
> > > experiences
> > > > in handling bug since quite some time.
> > > > I'm doing the bug triage of all incoming tickets that belong to the
> > > > ubuntu-z-systems project since about the last 20 month,
> > > > and also an administrator of the ubuntu-z-triage team:
> > > > https://launchpad.net/~ubuntu-z-triage/+members for IBM Z aka
> LinuxONE
> > > aka
> > > > s390x bugs.
> > > >
> > > > In addition to that I started to do the same (since this spring) for
> the
> > > > ubuntu-power-systems project, too:
> > > > https://launchpad.net/ubuntu-power-systems
> > > > And I also became an administrator of the
> > > > https://launchpad.net/~ubuntu-power-triage/+members triage team for
> IBM
> > > > Power bugs.
> > > >
> > > > I read "The Ubuntu Bug Control team" (ubuntu-bugcontrol) charter
> > > carefully
> > > > at: https://wiki.ubuntu.com/UbuntuBugControl
> > > > and even wrote another document called 'Bug Triage and Tracking
> Process'
> > > > (available Canonical internally:
> > > > https://docs.google.com/document/d/1LBQRmNk_96C3-
> > > p6enNrcoZreRV5tLr9_HzYNH71kToA
> > > > that goes beyond the usual bug control and handling aspects and lists
> > > some
> > > > IBM specifics things (like syncing bugs between launchpad and IBM
> > > bugzilla
> > > > - opening tickets against IBM etc.)
> > > >
> > > > And independent of this application for the UbuntuBugControl
> membership
> > > > I've read the generic requirements:
> > > > https://wiki.ubuntu.com/UbuntuBugControl#Generic-reqs
> > > > (discussed some special/corner-cases over time with several people
> like
> > > for
> > > > example xnox, dannf, manjo and others)
> > > > and even referenced the guidelines already in the past in the
> GoogleDoc I
> > > > mentioned above.
> > > >
> > > > An overview of some of my recent activities in LP and handling bugs
> > > > (roughly the last 2 days) can be found here:
> > > > https://launchpad.net/~frank-heimes/+karma
> > > > And a list of related bugs over there:
> > > > https://bugs.launchpad.net/~frank-heimes
> > >
> > > We'd like to see bugs that you are particularly proud of and represent
> > > your best work[1]. Could you provide us with that? Thanks!
> > >
> > > [1] "Please list five or more bug reports which you have triaged and
> > > include an explanation of your decisions. Please note that these bugs
> > > should be representative of your very best work and they should
> > > demonstrate your understanding of the triage process and how to
> properly
> > > handle bugs. For all the bugs in the list, please indicate what
> > > importance you would give it and explain the reasoning. Please use urls
> > > in your list of bugs." from wiki.ubuntu.com/UbuntuBugControl
> > >
> > > --
> > > Brian Murray
> > >
> --
> Brian Murray
>