Well, sorry, I need to put this topic and application aside for now, due to some urgent topics that I pretty promptly need to care about.
I would like to come back to this - and may re-apply - later again (and will adapt things based on your feedback and the experiences I made). Bye, Frank Frank Heimes | Tech. Lead Ubuntu Server on Z | Canonical Ltd. mail: frank.hei...@canonical.com irc: jfh www.canonical.com | www.ubuntu.com | ubuntu-on-big-iron.blogspot.com <http://ubuntu-on-big-iron.blogspot.com/?view=sidebar> On Mon, Jan 22, 2018 at 9:47 PM, Vej <ubu...@jonasdiekmann.de> wrote: > Hello Frank! > > Am 05.01.2018 um 23:25 schrieb Frank Heimes: > > Now again - and hopefully more precise: > > You are definitely heading in the right direction! > > > 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. > > Good. > > > 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 > > Okay for the Code of Conduct. What about the other documentations listed > here? Did you read and understood that? No questions left?! > > > 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. > > Sounds okay. > > > 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. > > Fits your previous messages. Although as a "desktop guy" I am wondering > what this has to do with the bugs selected for the next point: Are you > currently working elsewhere and plan to expand into this area or is > everything you wrote above part of "ubuntu-z-systems"? > > > 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. > > Sounds good. > > 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. > > I agree with that as well. > > 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). > > That argument seems legit, although it might not apply to all of these > packages (as Brian Murray wrote). I can not really decide that. > > > 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. > > It is hard to argue about your triaging work when you created the bug > yourself. The importance seems to be fine. > > I also want to warn you here that some projects dislike when creators of > bugs set the importance themselves (especially when the bug had not been > confirmed by anyone else before). Although that might be different for > people involved in that project (as a developer, tester or > (upstream-)triager). > > > 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. > > Sounds okay. > > > 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. > > The first one sound okay, the second one is out of my expertise again. > > Overall I am wondering if you have any bugs where you had to ask the > reporters for more informations or the like? From a Triaging point of view > these bugs would be more "your best work" than the ones provided, although > you might not have directly contributed to the solution. > > Undecided yet (+0). > > Best > > Vej >
_______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : ubuntu-bugcontrol@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
