ubuntu-bugcontrol team mailing list archive

[Frank Heimes <frank.heimes@xxxxxxxxxxxxx>]

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.

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.

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).

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.

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.

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.


Regards, 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 Fri, Jan 5, 2018 at 7:53 PM, Thomas Ward <teward@xxxxxxxxxx> wrote:

> Frank,
>
> In addition to what Vej said, you *must* read https://wiki.ubuntu.com/
> UbuntuBugControl#Application as well and pay attention to the specifics
> for the Direct Application; ***all*** items must be included and properly
> answered and addressed for an application to Bug Control:
>
> 1) Do you promise to be polite to bug reporters even if they are rude to
> you or Ubuntu? Have you signed the Ubuntu Code of Conduct?
>
> 2) Have you read Bugs/Triage, Bugs/Assignment, Bugs/Status and
> Bugs/Importance? Do you have any questions about that documentation?
>
> 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.
>
> 4) Is there a particular package or group of packages that you are
> interested in helping out with?
>
> 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.*
>
> Thomas Ward
> Ubuntu Server Team Member
> Ubuntu Bug Control Member
> LP: ~teward
>
>
>
> On 01/05/2018 01:38 PM, Vej wrote:
>
> Hello Frank.
>
> On 03.01.2018 Frank Heimes wrote:
>
> I hope that these aspects fit to requirements for a Ubuntu Bug Squad membership.
>
> No! This application is not about if and why you need this for your work. This is us deciding if you would make good use of the rights given, which is shown by an application following the procedure on the web page linked to you before.
>
> Please follow that, so we can see if your reasoning regarding importances makes sense. Please do so even if you do not intend to use the right to set these importances. We simply can not make you a member without giving you the right to set these.
>
> I hope this clarifies things for you. If not you might find it helpful to look at other applications and responses from in our public team mailing list archive at https://lists.launchpad.net/ubuntu-bugcontrol/
>  .
>
> Best
>
> Vej
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ubuntu-bugcontrol
> Post to     : ubuntu-bugcontrol@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol
> More help   : https://help.launchpad.net/ListHelp
>
>
>