ubuntu-bugcontrol team mailing list archive

[Frank Heimes <frank.heimes@xxxxxxxxxxxxx>]

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: frank.heimes@xxxxxxxxxxxxx
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 <frank.heimes@xxxxxxxxxxxxx>
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: frank.heimes@xxxxxxxxxxxxx
> 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 <teward@xxxxxxxxxx> 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     : ubuntu-bugcontrol@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>