ubuntu-bugcontrol team mailing list archive

[Gursimran singh <simar.i3r@xxxxxxxxx>]

First of all Thanks Phillip for your review :)

On Fri, Aug 6, 2010 at 4:06 AM, Philip Muskovac <yofel@xxxxxxx> wrote:

> On 08/05/2010 11:10 PM, Gursimran singh wrote:
> > Hi Ubuntu Bug Control Team,
> >              I am Gursimran singh Mohar
> > (https://edge.launchpad.net/~simar <https://edge.launchpad.net/%7Esimar>).
> I am currently being mentored by
> > Sense Hofstede for around a month now. Under his guidance and excellent
> > support I adopted and started triaging bugs for
> > xserver-xorg-input-synaptics, later moving to kernel related touchpad
> > bugs and covering all touchpad further. While triaging bugs related to
> > touchpad I realised that there is no proper Debugging Procedure written
> > for it, so I took a step forward and written it for the Ubuntu community.
> >
> > Now I have gained enough experience with the Ubuntu bug squad team, so I
> > look forward to join ubuntu Bug Control team. For that I answer the
> > following questions.
> >
> >    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?
> >          1. ya, sure. I'm quite aware of the fact that Ubuntu Bug Squad
> >             and Ubuntu Bug Control is the face of the ubuntu community
> >             that interfaces with end users and developers, so I'm sure,
> >             that how to deal with ubuntu users.
> >    2.
> >
> >       Have you read Bugs/HowToTriage
> >       <https://wiki.ubuntu.com/Bugs/HowToTriage>, Bugs/Assignment
> >       <https://wiki.ubuntu.com/Bugs/Assignment>, Bugs/Status
> >       <https://wiki.ubuntu.com/Bugs/Status> and Bugs/Importance
> >       <https://wiki.ubuntu.com/Bugs/Importance>? Do you have any
> >       questions about that documentation?
> >
> >          1. ya, no questions.
> >    3.
> >
> >       What sensitive data should you look for in a private Apport crash
> >       report bug before making it public? See Bugs/HowToTriage
> >       <https://wiki.ubuntu.com/Bugs/HowToTriage> for more information.
> >
> >          1.
> >
> >              We should not mark any bug public that contains
> >             CoreDump.gz. Either we should remove this attachment if
> >             stack track looks good.
> >
> >          2. If the bug report contain Stacktrace.txt, this may include
> >             passwords, credit card numbers and other sensitive data,
> >             which may have passed as function arguments and logged. So
> >             we need to check for this data before marking the bug report
> >             as public, or we may wish to keep it private throughout the
> >             lifespan of the bug.
> >
> >    4. Is there a particular package or group of packages that you are
> >       interested in helping out with?
> >          1. As I mentioned I have work for touchpad bugs, I would like
> >             to continue with it. Meanwhile I look forward to triage bugs
> >             with JFo for Kernel. I have talked to JFo about this in
> >             #ubuntu-kernel. For the same currently I am reading
> >             documentation of Kernel Triage.
> >
> >    5. Please list five or more bugs which you have triaged. These bugs
> >       should demonstrate your understanding of the triage process and
> >       how to properly handle bugs. If there is a bug in your list that
> >       does not have an importance indicate what importance (and explain
> >       the reasoning) you would give it after becoming a member of Ubuntu
> >       Bug Control. Please use urls in your list of bugs.
> >          1.
> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/591656
>
> Good work
>

Thanks.


>
> >          2.
> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/554980
> >                1. Importance - Low
> >                2. As this 'affect unusual configurations or uncommon
> >                   hardware'.
>
> Good work at getting the information and at staying calm ;)
>

I tried to have the responsibility, as the face of ubuntu community.

>
> >          3.
> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/565543
>
> ok, getting a full Xorg.0.log would have made things easier though as
> chris pointed out. Also before assigning bugs to the kernel it helps to
> at least get the boot dmesg output IMHO. (Check out
> https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies to see what
> they want as minimum info on a report)
>

I will be shortly migrating to kernel after I get in ubuntu bug control. I
hope to learn these policies soon as I will work for kernel team. I am aware
of some of these that were told by JFo at UDW for others this link will
help. Thanks for the link :)

>
> >          4.
> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/159968
> >                1. Importance - Low
> >                2. As this 'Ones that affect unusual configurations or
> >                   uncommon hardware' and affect a few people.
>
> good work so far
>
> >          5.
> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/462166
> >                1. Improtance - Low
> >                2. As this 'affect unusual configurations or uncommon
> >                   hardware' only affects in Synaptics Touchpad version
> >                   7.2 and is due to the fact that Synaptics is not
> >                   willing to disclose its multitouch protocol.
>
> From what I know about touchpads (which isn't that much tbh.) this is a
> very hw-specific bug, so I think you're right there. Considering that
> and the fact that the original reporter unsubscribed you did a rather
> good job. (Please refrain from comments like #28 though, at least to me
> that sounds a bit offensive)
>

ya, but I have learnt much since then. I attended UDW and some (rather a lot
of IRCs) with Sense has made a more clear picture of what a bug triager
really is. I have proven this the other bug report that I mentioned above.

>
> Still a +1 from me since you also do a great job on the debugging
> documentation.
>

I really look forward to help with documentation in future also. :)