ubuntu-bugcontrol team mailing list archive

[Brian Murray <brian@xxxxxxxxxxxxx>]

On Fri, Jan 05, 2018 at 11:25:52PM +0100, Frank Heimes wrote:
> Hi,
> okay, looks like I should better stick more strictly to the application
> section of the UBC wiki page.
> 
> (I think I covered most of the bullets anyway in this thread, but I may
> missed item #3 and didn't go deep enough into all details for #5 ... maybe
> I didn't read the replies carefully enough during my PTO - anyway ...)
> 
> Now again - and hopefully more precise:
> 
> 1)
> Do you promise to be polite to bug reporters even if they are rude to you
> or Ubuntu?
> ---
> Yes, absolutely, I promise to be polite. Being rude doesn't help at all.
> And I guess you will not find a rude statement or sentence in any of the LP
> bugs I worked on so far.
> 
> 2)
> Have you signed the Ubuntu Code of Conduct? Have you read Bugs/Triage,
> Bugs/Assignment, Bugs/Status and Bugs/Importance? Do you have any questions
> about that documentation?
> ---
> Yes, as on can see here: https://launchpad.net/~frank-heimes
> 
> 3)
> What sensitive data should you look for in a private apport crash report
> bug before making it public? See Bugs/Triage for more information.
> ---
> I should look for any private information that shouldn't be exposed to the
> public, like:
> passwords, keys, account numbers and other private user data
> as well as further sensitive data, like server or network infrastructure
> layouts and details
> Special care should be taken about log files, core dumps, stack traces -
> either available as dedicated files or as part of bundles or compressed
> files.
> 
> 4)
> Is there a particular package or group of packages that you are interested
> in helping out with?
> ---
> 's390-tools' package and s390x-specific d-i installer - means the base
> group of packages required for s390x installations.
> libica(2,3) and openssl-ibmca (, opencryptoki) - means the group of
> packages required for hardware crypto exploitation.
> So all quite Ubuntu Server focused.
> 
> 5)
> 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.
> ---
> 
> 5.1)
> "PCI RoCe IB perftest Aborted (core dumped)"
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1553185
> This bug was opened before I joined Canonical and at some point in time I
> took it over.
> I've setup a test environment, went with 'paelzer' into more details, after
> the problem was identified and fixed, I also tested the fix.
> But I needed to push Mellanox for more than 6 month to get this problem
> upstream fixed.
> Once it became officially available xnox was also to update our package,
> based on the latest Mellanox code and I did some final verifications.
> I would probably have rated this with importance medium, because it affects
> a non-core and usually non-severe application.
> But because it blocked a prove of functionality of a customer application
> (and of IB itself on all platforms) it was set to high.

One thing worth noting is that is possible for the different bug tasks
to have different importances. So in this case I'd think the
ubuntu-z-systems project bug task could have a high importance because
of the customer applications, but the perftest bug should have a medium
importance for the reason you've given. Otherwise, the work here looks
good.

> 5.2)
> "libdapl2: PCI RoCe IB dapltest does not recognize updated names of
> /etc/dat.conf entries"
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1553183
> It is clearly a Medium importance ticket, because it only affected a
> non-core and non-severe application, didn't blocked anything else and a
> workaround was available (name can also be changed w/o dat.conf).
> It just occurred (and was raised) during a customer test case.
> Since a massive update on the Mellanox rdma and IB stack before we were
> finally able to tackle this ticket, too.

This seems fine.

> 5.3)
> "Update to newer version of docker-compose >= 1.6"
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1637223
> This one is an example about what we usually don't do that often - package
> upgrade within an Ubuntu release.
> But this time it was required and desired by different parties.
> I worked behind the scenes on that with 'mwhudson' and did the final
> verification.
> The Importance is was set to High because it has a severe impact on all
> Ubuntu users that intent to use docker-compose and it prevents
> docker-compose to functioning at all - even if docker and docker-compose
> are no core components, but this all worked before, hence it was a
> regression and also marked as regression-update).

This too looks good.

> 5.4)
> "Low-level DASD format fails on artful d-"
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1718463
> Sometimes I also open tickets by myself and also work on 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.
> It could prevent default Ubuntu installation from being successful (ending
> in an error screen) - in case disks were used for the first time (and
> low-level format is needed). Hence the importance was set to High.

Well its a great bug description so while not an ideal example this is
fine.

> 5.5)
> "s390/mm: fix write access check in gup_huge_pmd()"
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1730596
> The problem described in this ticket can potentially lead to data loss.
> It was opened by IBM because it already happened to at least one (other
> non-Ubuntu Linux system), hence they opened this 'preventive' ticket, so
> that no further customer will hit this.
> I set the Importance to Critical due to the potential data-loss and to get
> it SRUed as soon as possible.

I agree with the importance on this bug report. Its not quite clear to
me what your involvement with the bug report was though - I just see
some tags being changed.

> 5.6)
> I'm also passing over ticket reported by fellows (like our testers) to IBM
> and made sure that they got upstream accepted.
> These two examples describe minor issues:
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1633513
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1616590
> So I've set them to Low (at least Importance on the ubuntu-z-systems
> project); due to insufficient privileges I cannot adjust the s390-tools
> package Importance.

Keep in mind the question "was what importance would you give it?" Here
I also don't see a lot of triaging work done on the bug report by you.

Right now I'd have to vote +0 given some of the bugs where not much work
was done.

I was trying to find a previous application that demonstrates what I'm
looking for but come to find out its not on the LP mailing list archive
for some reason. Here's one bug from that application (Mathew Hodson's).

"https://bugs.launchpad.net/ubuntu/+source/gnome-calculator/+bug/1380561
Bug confirmed. Clarified title, rewrote description, which was
conflating two issues, and linked to the other issue. Importance Low
because it has a limited impact on a core application."

Here the triager has confirmed the bug, added a test case to the
description and improved the title. It is examples like this that we are
looking for in the bug report.

I'll go ahead and forward Mathew's original application to the list as a
reference to which we can point.

--
Brian Murray

Attachment: signature.asc
Description: PGP signature