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: [email protected] 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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol > More help : https://help.launchpad.net/ListHelp > > >
_______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
