The application process asks that you indicate what importance you would give and explain the reasoning the bug report since that is a new ability that you would have.
Thanks! Brian On Wed, Dec 13, 2017 at 09:47:57PM +0100, Frank Heimes wrote: > Hi, > so I have a list of 10 examples. > > These are probably not absolute perfect ones, but show the variety and > differences: > > > this was a really long running bug ticket. > It was even opened before I joined Canonical and at some point in time I > took it over from dannf. > I needed to push Mellanox for more than 6 month to create an upstream for > for that issue. > Once it became officially availabel xnox was also to update our package > based on the latest Mellanox code and I did some final verifications. > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1553185 > > the massive updates on the Mellanox rdma and ib stack fortunately helps to > tacke other related tickets like this: > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1553183 > this is till not yet fix released because the guy (from IBM) who originally > openend that ticket was not yet able to verify it > (but I verified it on one of our systems) > > the next one is an example about what we usually don't do that often - > package upgrade with an buntu release > but this time it was required and desired by different parties > I worked behind the scenes on that with mwhudson - it was quite complex due > to lot's of dependencies > at the end I again did the final verification > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1637223 > > sometimes I for sure also open tickets by myself and work on closing 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 > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1718463 > > sometimes our hardware certification team is running into an issue that I > work on > in this example I found after having a look at the logs that the issue is > due to our (at that time) outdated zVM hypervisor > I updated it and applied a patch on top and we verified that the problem > got solved (this time reported by xnox) > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1666679 > > this is an example of regression (in the docker space), with multiple > releases involved: > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1658009 > > this is a totally different example, it's about the lack of the container > live migration feature on the s390x platform > I opened that ticket in LP, but then synched over to IBM, because IBM is > responsible for any base enablement and porting of tools for the s390x > (process fr that is described in my GoogleDoc mentioned before) platform, > IBM team completed the porting over time and brought the needed patches > upstream > and in between we have CRIU for s390x starting with 17.10 as the first > Linux distro > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1635845 > > this kpatch-build ticket is similar - IBM needs to work on that (and still > does) > before we may think about offering kernel live-patch for the s390x > platform, too: > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1639924 > > I'm also passing over ticket reported by other (like our testers) to IBM - > see these two examples of minor issues: > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1633513 > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1616590 > > an example where I reported a (non critical) issue that is unfortunately > hard to solve > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1704929 > we still have no idea how to solve that (how to get rid of these msgs) - > for now we at least tracked it down to a kernel problem > and because this is probably arch specific we looking at it jointly with > IBM ... > > another example where I only somehow managed the ticket - with several > parties and Ubuntu releases involved > https://bugs.launchpad.net/ubuntu-z-systems/+bug/1595192 > > Please keep in mind that I needed to ask a colleague from time to time in > the past to assign tasks to the right parties and people, > just because I don't have the needed permissions in LP I am applying for. > > > 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> | > http://fridge.ubuntu.com > > On Wed, Dec 13, 2017 at 8:28 PM, Brian Murray <br...@canonical.com> wrote: > > > On Wed, Dec 13, 2017 at 03:21:12PM +0100, Frank Heimes wrote: > > > Thanks Vej ! > > > > > > Hi Brian, looks like I always end up with you :-) > > > > > > Since I don't expect that my job and role changes soon, I think getting > > > access granted as an employee of Canonical is probably not bad. > > > > > > But anyway, I'm happy to officially apply as an individual: > > > > > > I've already signed the ubuntu code of conduct and have already > > experiences > > > in handling bug since quite some time. > > > I'm doing the bug triage of all incoming tickets that belong to the > > > ubuntu-z-systems project since about the last 20 month, > > > and also an administrator of the ubuntu-z-triage team: > > > https://launchpad.net/~ubuntu-z-triage/+members for IBM Z aka LinuxONE > > aka > > > s390x bugs. > > > > > > In addition to that I started to do the same (since this spring) for the > > > ubuntu-power-systems project, too: > > > https://launchpad.net/ubuntu-power-systems > > > And I also became an administrator of the > > > https://launchpad.net/~ubuntu-power-triage/+members triage team for IBM > > > Power bugs. > > > > > > I read "The Ubuntu Bug Control team" (ubuntu-bugcontrol) charter > > carefully > > > at: https://wiki.ubuntu.com/UbuntuBugControl > > > and even wrote another document called 'Bug Triage and Tracking Process' > > > (available Canonical internally: > > > https://docs.google.com/document/d/1LBQRmNk_96C3- > > p6enNrcoZreRV5tLr9_HzYNH71kToA > > > that goes beyond the usual bug control and handling aspects and lists > > some > > > IBM specifics things (like syncing bugs between launchpad and IBM > > bugzilla > > > - opening tickets against IBM etc.) > > > > > > And independent of this application for the UbuntuBugControl membership > > > I've read the generic requirements: > > > https://wiki.ubuntu.com/UbuntuBugControl#Generic-reqs > > > (discussed some special/corner-cases over time with several people like > > for > > > example xnox, dannf, manjo and others) > > > and even referenced the guidelines already in the past in the GoogleDoc I > > > mentioned above. > > > > > > An overview of some of my recent activities in LP and handling bugs > > > (roughly the last 2 days) can be found here: > > > https://launchpad.net/~frank-heimes/+karma > > > And a list of related bugs over there: > > > https://bugs.launchpad.net/~frank-heimes > > > > We'd like to see bugs that you are particularly proud of and represent > > your best work[1]. Could you provide us with that? Thanks! > > > > [1] "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." from wiki.ubuntu.com/UbuntuBugControl > > > > -- > > Brian Murray > > -- Brian Murray
signature.asc
Description: PGP signature
_______________________________________________ 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
