ubuntu-bugcontrol team mailing list archive

[Frank Heimes <frank.heimes@xxxxxxxxxxxxx>]

Dear Ubuntu Bug Control team,
I'm Frank (jfh) and hereby I'd like to apply for the Launchpad
'ubuntu-bugcontrol' team membership.

My 'coordinates':
     https://wiki.ubuntu.com/FrankHeimes
     Launchpad: https://launchpad.net/~frank-heimes
     IRC: jfh

I've again carefully read the requirements for joining at
https://wiki.ubuntu.com/UbuntuBugControl as well as the referenced
pages/documents.
I'm doing triage work since a while and I'm a member of the Launchpad
“Ubuntu BugSquad” team for more than two years now.
_________

Application:

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?

I think I was always polite in the past and will be in future in any
communication (not only) with bug reporters (Launchpad, mailing-lists,
etc.) - regardless if it's a community member or customer.
I've signed the Code of Conduct in 2016, when I got more and more involved
in Launchpad and bug activities.


2. Have you read Bugs/Triage, Bugs/Assignment, Bugs/Status and
Bugs/Importance? Do you have any questions about that documentation?

I've read the docs about Bug Triage, Bug Assignment, Task status,
Importance (and further referenced pages) and applied the content several
times,
but nevertheless, I'm still looking-up and considering the bug wiki pages
from time to time.
Since I'm dealing with customers I explained the procedure(s) several times
and referenced to these pages.
I especially like the Triage Charts page (
https://wiki.ubuntu.com/Bugs/Triage/Charts) that provides a crisp overview
of the flows.


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.

Before marking bugs with (apport) crash reports (or other dumps) public, it
needs to be ensured that no sensitive information is disclosed.
This can be personal or customer information mainly in the stacktrace, like
user/server names, (bank) account data, passwords/passphrases, (private)
encryption keys or other information that looks like it should not be
disclosed.
A bug should never be made Public in case it still has a CoreDump.gz
attachment or in case one is unsure (one may ask at #ubuntu-bugs for help).
(Notice, it's not required to make a bug public - bugs may stay private for
their entire lifetime.)


4. Is there a particular package or group of packages that you are
interested in helping out with?

I'm particularly interested in platform specific packages of the s390x and
ppc64el platforms, like s390-tools, smc-tools - since I'm familiar with
this special hardware and have access to such systems. I'm getting
automatically subscribed to all bugs of the LP projects ubuntu-z-systems
and ubuntu-power-systems.
I also like to help fixing kernel issues (e.g. bugs or config changes) and
drive things forward by submitting kernel SRUs.


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.

LP 1814521 - [UBUNTU] - opencryptoki: EP11 token fails when using
Strict-Session mode or VHSM-Mode
https://bugs.launchpad.net/bugs/1814521
==> Opencryptoki patch needed to fix errors is crypto hardware that runs in
EP11 (PKCS#11) mode
- triaged ticket and assigned it to Foundations team
- and updated the bug description, since the descriptions was accidentally
added as comment
- Foundations took over the ticket
- I supported in adding the package SRU justification (also on IRC request)
and adjusting tags

LP 1847109 "Ubuntu 18.04 - wrong cpu-mf counter number"
https://bugs.launchpad.net/bugs/1847109
==> wrong number in cpu-mf counter LAST_HOST_TRANSLATIONS leads to
confusion in the counter usage - probably the simplest kernel patch and SRU
possible (fixing one single hex value)
- triage the bug and set the Importance to Medium
  ("A problem with a non-essential hardware component": CPU management
facility counter)
- this problem was very easy recreatable, even by code inspection, I could
verify and finally confirm it
- slightly changed (simplified) the summary (headline) - in preparation for
the kernel SRU
- since it's a trivial kernel patch, cloned Bionic master-next,
cherry-picked, compiled and tested a modified kernel
- submitted a kernel SRU, added Justification to bug description and
changed status to 'In Progress'
- kernel team took over ... and added Linux (Ubuntu) - Bionic nomination
  (I was asked by the kernel team to do this, but wasn't able, since I
don't have the permissions on LP; hence one reason for this application)
- adjusted the tags after successful verification of the reporter (who
forgot the change the verification tag)
- (now waiting for the kernel SRU cycle to be completed ...)

LP 1848492 - Change Config Option CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE for
s390x from yes to no
https://bugs.launchpad.net/bugs/1848492
==> request kernel config change to ensure expected behaviors for dynamic
RAM usage
- triaged the bug, marked it as affecting a certain project and set
Importance High
  ("A problem with an essential hardware component": RAM)
- asked the bug reporter for further clarification
- answer allowed me to work on that by myself, hence confirmed and slightly
adjusted summary (headline) - in preparation for the kernel SRU
- created patch (needed for kernel config change), compiled and tested
kernel
- submitted Kernel SRU, added Justification and changed Status to 'In
Progress'
  (had no privileges to add nomination for the various affected Ubuntu
releases, hence a kernel team member needed to do that)
- did the verifications for the nominated series and adjusted the tags

LP 1848173 "Ubuntu 16.04.6 - Shared CEX7C cards defined in z/VM guest not
established by zcrypt device driver"
https://bugs.launchpad.net/bugs/1848173
==> request to apply attached kernel patch to fix situation of not being
able to use 'CryptoExpress' cards on Xenial
- triaged bug, marked it as affecting a certain project and set Importance
to Medium
  ("A bug which impacts accessibility of a non-core application":
CryptoExpress adapter card)
- slightly changed summary/headline (in prep. for a kernel SRU)
- applied attached patch, compiled and successfully (regression-) tested
modified kernel
- submitted a kernel SRU, added Justification to bug description and
changed status to 'In Progress'
- kernel team took over ... and added Linux (Ubuntu) - Xenial nomination
  (I was asked by a kernel team member to do this, but couldn't since I do
not have the permissions to do so for the kernel entry.)
- adjusted the tag after successful verification of the reporter (who
forgot to update the verification tags)

LP 1781242 - as segfault with invalid -march= option
https://bugs.launchpad.net/bugs/1781242
==> GNU assembler segfaults using invalid -march option
- triaged bug, marked it as affecting a certain project and set Importance
to Low
  ( "Bugs that have easy work-arounds"; "Bugs that affect unusual end-user
configurations")
- changed affecting package (from kernel to binutils) and assigned it to
Foundations
- double-checked that it's only affecting Xenial and aligned project states
- finally (successfully) verified on Xenial and updated tags

LP 1845323 - Trying to online dasd drive results in invalid input/output
from the kernel on z/VM
https://bugs.launchpad.net/bugs/1845323
==> Severe problem that breaks installation on a specific platform for a
large part of users; occurred shortly before Eoan beta started
- triaged the bug, set affected package, changed from Incomplete (due to
bot) to New - learned about the "bot-stop-nagging" tag later
- could recreate the problem and confirmed,just
  hence changed status to confirmed and importance to critical
  ("Makes a default Ubuntu installation <on s390x> generally unusable for
some users" - High
   "Renders the system temporarily or permanently unusable <during
install>" - Critical
   this was pretty urgent, since it occurred on start of Eoan beta testing,
hence the decision to mark it as critical
   (this also blocked the generation of s390x beta images; I've added this
bug in the QA ISO Tracker, too)
- involved hypervisor vendor and received a patch on short notice
- patch was SRUed by Foundation/Kernel set of people, tried out the patch
and helped on the SRU justification
- successfully verified as part of SRU process, and adjusted status

LP 1841984 - [Backport] Crypto VMX Fixes
<https://bugs.launchpad.net/ubuntu-power-systems/+bug/1841984>
https://bugs.launchpad.net/bugs/1841984
==> backport needed to address integrity issues on hardware assisted crypto
- while triaging this bug I noticed a relationship to a different bug and
clarified things,
- marked ticket as affecting certain project and set Importance to High,
due to:
  'severe impact on a small portion of Ubuntu users': data integrity, but
only in case of crypto usage on Power
- quick analysis of commit ID (in Disco master-next tree) showed that the
requested patches do not need to be separately SRUed,
  since they were already addressed by an upstream release update, hence
suggested to wait for the completion of this
- I decided to not mark it as a duplicate, since it was just by coincidence
covered by an upstream release update
  (upstream release updates are not opened to address a single and specific
problem, rather than to keep the kernel in sync with all upstream
maintenance work and enhancements - hence the two tickets are not the
"same")
- monitored state of patches and upstream release update and adjusted the
status over time until Fix Released


Please notice that I partly worked beyond triaging, due to my work in
'hardware enablement'.
If more information about the two LP projects (
https://launchpad.net/ubuntu-z-systems and
https://launchpad.net/ubuntu-z-systems) that I'm largely working on are
desired, I'm happy to share more details (since there are some special
agreements with those).


Thanks for considering me
BR, Frank (jfh)