ubuntu-bugcontrol team mailing list archive

[Vej <ubuntu@xxxxxxxxxxxxxxxx>]

Hello Frank!

Am 05.01.2018 um 23:25 schrieb Frank Heimes:
> Now again - and hopefully more precise:
You are definitely heading in the right direction!
>
> 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.
Good.
>
> 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 <https://launchpad.net/%7Efrank-heimes>
Okay for the Code of Conduct. What about the other documentations listed here? Did you read and understood that? No questions left?!
>
> 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.
Sounds okay.
>
> 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.
Fits your previous messages. Although as a "desktop guy" I am wondering what this has to do with the bugs selected for the next point: Are you currently working elsewhere and plan to expand into this area or is everything you wrote above part of "ubuntu-z-systems"?
>
> 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 <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.
Sounds good.
> But because it blocked a prove of functionality of a customer application (and of IB itself on all platforms) it was set to high.
>
> 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 <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.
I agree with that as well.
> Since a massive update on the Mellanox rdma and IB stack before we were finally able to tackle this ticket, too.
>
> 5.3)
> "Update to newer version of docker-compose >= 1.6"
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1637223 <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).
That argument seems legit, although it might not apply to all of these packages (as Brian Murray wrote). I can not really decide that.
>
> 5.4)
> "Low-level DASD format fails on artful d-"
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1718463 <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.
It is hard to argue about your triaging work when you created the bug yourself. The importance seems to be fine.

 I also want to warn you here that some projects dislike when creators of bugs set the importance themselves (especially when the bug had not been confirmed by anyone else before). Although that might be different for people involved in that project (as a developer, tester or (upstream-)triager).
>
> 5.5)
> "s390/mm: fix write access check in gup_huge_pmd()"
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1730596 <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.
Sounds okay.
>
> 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/1633513>
> https://bugs.launchpad.net/ubuntu-z-systems/+bug/1616590 <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.
The first one sound okay, the second one is out of my expertise again.

Overall I am wondering if you have any bugs where you had to ask the reporters for more informations or the like? From a Triaging point of view these bugs would be more "your best work" than the ones provided, although you might not have directly contributed to the solution.

Undecided yet (+0).

Best

Vej