ubuntu-bugcontrol team mailing list archive

[Frank Heimes <frank.heimes@xxxxxxxxxxxxx>]

Well, sorry, I need to put this topic and application aside for now, due to
some urgent topics that I pretty promptly need to care about.

I would like to come back to this - and may re-apply - later again (and
will adapt things based on your feedback and the experiences I made).

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>

On Mon, Jan 22, 2018 at 9:47 PM, Vej <ubuntu@xxxxxxxxxxxxxxxx> wrote:

> 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
>
> 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
> 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
> 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
> 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
> 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
> 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/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
>