ubuntu-bugcontrol team mailing list archive

[Myles Penner <myles.penner@xxxxxxxxxxxxx>]

To the Ubuntu Bug Control Team,

Please see my following application for membership in the Ubuntu Bug
Control team.

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?

Yes, I promise to always be polite and professional when interacting online
on behalf of Ubuntu. I understand that encountering software bugs can be
frustrating for users and some can feel quite passionately about it. It is
important to empathize with the user and make them feel heard, while
gathering necessary information to address the issue. I have signed the
Ubuntu Code of Conduct as part of my onboarding process with Canonical.

2. Have you read Bug triage, Bug status, and Bug importance? Do you have
any questions about that documentation?

Yes, I have read those documents and have put them into practice when
triaging and addressing snap-openstack (Sunbeam) bugs for the Ubuntu
OpenStack team. I have no questions about the contents.

3. What sensitive data should you look for in a private Apport crash report
bug before making it public?

Apport crash reports should have the CoreDump.gz files removed since they
could contain sensitive data about a user's system. If the stack trace is
good enough, the CoreDump.gz should be removed from the report (mark
'invalid,' if not). A bug report containing CoreDump.gz should never be
made public. In general, the bug report should be looked over for any
sensitive or identifying information such as passwords, user names, server
names, IP addresses, API keys, banking information, etc.

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

I am currently on the OpenStack bug triage team and would like to have my
privileges expanded for all Ubuntu packages to assist with my work with the
MIR team. MIR reports are written as bugs and when an MIR is identified as
requiring a security review, the Ubuntu Security team needs to be assigned.
My current privilege does not allow me to assign bugs outside of my own
team.

5. List five or more bug reports you have triaged, and include an
explanation of your decisions. These bugs should represent your very best
work and they should demonstrate your understanding of the triage process
and how to properly handle bugs. For each bug in the list, indicate what
importance you would give it and explain the reasoning. Provide URLs in
your list of bugs.


   1. https://bugs.launchpad.net/snap-openstack/+bug/2122469 - This bug is
   related to the '^C' command causing issues with the terminal when used on a
   Sunbeam process. I triaged this bug as a 'medium' as while it presents a
   usability glitch when a process is terminated prematurely, a workaround was
   presented by the bug reporter. This is the type of issue that should be
   fixed in the medium term but does not present an issue with deployment or
   setup of Sunbeam which would take precedence.
   2. https://bugs.launchpad.net/snap-openstack/+bug/2114956 - This bug is
   related to a Tempest test failure when running the standard smoke test for
   Sunbeam in the CI environment. This was triaged as a 'medium' priority bug
   as this bug was intermittent, likely exposing an occasionally-occurring
   race condition within Sunbeam when run on the QA CI environment. This issue
   cannot be reproduced locally so it is not presenting an issue to end users
   but should be fixed in the medium term as any failures that present in QA
   could be masking other problems with the product.
   3. https://bugs.launchpad.net/snap-openstack/+bug/2106130 - This bug
   relates to incorrect documentation links within Sunbeam. This was also
   triaged as a medium (and promptly fixed by myself as I was already working
   on that part of the codebase) because the links in question were to the old
   documentation set which was still up and valid, but we wanted to move all
   internal references to the new Sunbeam documentation set at a different
   domain. This bug did not present an immediate usability or quality-of-life
   issue to a user but should have been fixed relatively quickly as the old
   documentation set was being taken offline within a couple months of the
   report.
   4. https://bugs.launchpad.net/snap-openstack/+bug/2110524 - This bug
   relates to a user request for the 'manifest' file of Sunbeam to be routable
   to 'stdout' rather than only to a file. This was triaged as a 'wishlist'
   item because Sunbeam was designed to only create a manifest.yaml file and
   not direct the manifest to stdout. This is not a problem with the way the
   product was intended to work, however, that is a reasonable feature request
   and something that could be added in future work.
   5. https://bugs.launchpad.net/snap-openstack/+bug/2101130 - This bug is
   related to the Tempest output not being created at all when a test fails.
   This was triaged as 'high' because this presents a significant blind spot
   in our QA CI environment and makes it extremely difficult to know what
   triggered a failure when one occurs. This is a higher priority than a bug
   labelled 'medium' because it presents an issue when any CI failure occurs,
   not just a specific failure, but it is not critical as it does not present
   a blocking issue for an end-user of Sunbeam in production. It is the type
   of issue that should be fixed within a week.

Thank you for your consideration. Please let me know if you need any
further supporting documentation.


Kindly,

Myles Penner (~mylesjp)