Forgot to mention the rational for setting bugs mentioned in 5.6 to Low. They are just cosmetic/usability issues, don't cause functional degradations and can easily be circumvented.
Thx, 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 11:25 PM, Frank Heimes <[email protected]> wrote: > 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
