FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 06-18-2012, 12:01 PM
"Christopher Penalver"
 
Default https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997767/comments/80

Dear Kernel Team:



In response to Brad Figg's post:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997767/comments/80



>"You are really not helping by just spamming bugs..."



I take the work I do as a volunteer Bug Control member very seriously. I do not appreciate being publicly flogged in having my triaging efforts called spam, in light of this being proper Bug Control procedure as per thread:

https://lists.launchpad.net/ubuntu-bugcontrol/msg03737.html



and:

https://wiki.ubuntu.com/Bugs/Tags#Regression_specific



>"...telling folks to bisect their kernels."



I'm not telling anyone to bisect their kernels. All I do is ask if they could do it, and if they cannot, work together with them to have it bisected for them.



>"Many people just are not prepared to do so."



I think judging the technical ability of many people before they told us is presumptuous and arbitrary. It seems best to let the reporter decide if they can or cannot bisect, and then work together with them based on this. Examples exist where I requested the reporter to bisect, they did, and the bug moved forward.



Despite this, if the team does not find asking the reporter to bisect to be proper, in light of their bug being a regression, then I clearly do not understand Ubuntu kernel bug triage, nor linux kernel regressions in general.



It is appreciated if the team clears this issue up so I and other Bug Control members who want to triage kernel bugs can be as helpful and productive as possible.



What do you think?



--

Christopher*M.*Penalver

E-Mail:*christopher.penalver@gmx.com

MCSE:Security,*MCSA,*MCDST,*MCP,*Security+,*Networ k+,*A+,*NSSP



This*E-Mail*was*sent*via*a*laptop*using*Xubuntu,*Linux*fo r*human*beings.

www.xubuntu.org

http://www.launchpad.net/~penalvch

Acer*Aspire*5750-9668*Xubuntu*12.04
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-18-2012, 03:08 PM
Brad Figg
 
Default https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997767/comments/80

On 06/18/2012 05:01 AM, Christopher Penalver wrote:
> Dear Kernel Team:
>
> In response to Brad Figg's post:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997767/comments/80
>
> >"You are really not helping by just spamming bugs..."
>
> I take the work I do as a volunteer Bug Control member very seriously. I do not appreciate being publicly flogged in having my triaging efforts called spam, in light of this being proper Bug Control procedure as per thread:
> https://lists.launchpad.net/ubuntu-bugcontrol/msg03737.html
>
> and:
> https://wiki.ubuntu.com/Bugs/Tags#Regression_specific
>
> >"...telling folks to bisect their kernels."
>
> I'm not telling anyone to bisect their kernels. All I do is ask if they could do it, and if they cannot, work together with them to have it bisected for them.
>
> >"Many people just are not prepared to do so."
>
> I think judging the technical ability of many people before they told us is presumptuous and arbitrary. It seems best to let the reporter decide if they can or cannot bisect, and then work together with them based on this. Examples exist where I requested the reporter to bisect, they did, and the bug moved forward.
>
> Despite this, if the team does not find asking the reporter to bisect to be proper, in light of their bug being a regression, then I clearly do not understand Ubuntu kernel bug triage, nor linux kernel regressions in general.
>
> It is appreciated if the team clears this issue up so I and other Bug Control members who want to triage kernel bugs can be as helpful and productive as possible.
>
> What do you think?
>

Looking at this specific bug (997767):

1. Comment #3 from the reporter: ".. the problem manifests only when KDE/X11
is running".

Maybe it's not a kernel bug..

2. Comment #4. It is not obvious from the comment but what the reporter did
was he installed the 2.6.38 kernel on Precise (12.04). When the submitter
was running Natty (2.6.38) he did not have this problem. So, this would
also point towards a user-space problem being the source of the issue.

3. The submitter was asked to test a mainline kernel and was not able to do
so. You asked what happened and they replied. You then asked them to
try another mainline kernel. Again, they said they were not able to do
so.

4. At this point you asked them to start bisecting their kernel. In order
to do so you have to:

1. Believe that it is a kernel bug (which is still not clear from any
of the comments).

2. Have a "good kernel" starting point and a "bad kernel" starting
point.

If you were to do the bisection yourself, what would _you_ use for
those two tags to diagnose this bug?

5. Your comment #78 says: "The next step is to perform a bisect to identify
the offending commit(s). Could you please do so following
https://wiki.ubuntu.com/Kernel/KernelBisection ?" And you set the status
of the bug to "Incomplete".

This sounds exactly like you telling the user to go bisect the kernel
and come back when they are done.

In conclusion, I stand by everything in my comment.

> --
> Christopher M. Penalver
> E-Mail: christopher.penalver@gmx.com
> MCSE:Security, MCSA, MCDST, MCP, Security+, Network+, A+, NSSP
>
> This E-Mail was sent via a laptop using Xubuntu, Linux for human beings.
> www.xubuntu.org
> http://www.launchpad.net/~penalvch
> Acer Aspire 5750-9668 Xubuntu 12.04
>
>
>
>

Brad
--
Brad Figg brad.figg@canonical.com http://www.canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-18-2012, 04:09 PM
"Christopher Penalver"
 
Default https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997767/comments/80

Brad:

Thank you for getting back to me on this. Regarding your comments:

*----- Original Message -----
*From: Brad Figg
*Sent: 06/18/12 11:08 AM
*To: Christopher Penalver
*Subject: Re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997767/comments/80

*
On 06/18/2012 05:01 AM, Christopher Penalver wrote:
> Dear Kernel Team:
>
> In response to Brad Figg's post:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997767/comments/80
>
> >"You are really not helping by just spamming bugs..."
>
> I take the work I do as a volunteer Bug Control member very seriously. I do not appreciate being publicly flogged in having my triaging efforts called spam, in light of this being proper Bug Control procedure as per thread:
> https://lists.launchpad.net/ubuntu-bugcontrol/msg03737.html
>
> and:
> https://wiki.ubuntu.com/Bugs/Tags#Regression_specific
>
> >"...telling folks to bisect their kernels."
>
> I'm not telling anyone to bisect their kernels. All I do is ask if they could do it, and if they cannot, work together with them to have it bisected for them.
>
> >"Many people just are not prepared to do so."
>
> I think judging the technical ability of many people before they told us is presumptuous and arbitrary. It seems best to let the reporter decide if they can or cannot bisect, and then work together with them based on this. Examples exist where I requested the reporter to bisect, they did, and the bug moved forward.
>
> Despite this, if the team does not find asking the reporter to bisect to be proper, in light of their bug being a regression, then I clearly do not understand Ubuntu kernel bug triage, nor linux kernel regressions in general.
>
> It is appreciated if the team clears this issue up so I and other Bug Control members who want to triage kernel bugs can be as helpful and productive as possible.
>
> What do you think?
>

Looking at this specific bug (997767):

1. Comment #3 from the reporter: ".. the problem manifests only when KDE/X11
is running".

Maybe it's not a kernel bug..

-> Agreed, maybe it's not.

2. Comment #4. It is not obvious from the comment but what the reporter did
was he installed the 2.6.38 kernel on Precise (12.04). When the submitter
was running Natty (2.6.38) he did not have this problem. So, this would
also point towards a user-space problem being the source of the issue.

-> Agreed, that it points towards, but not solidifies, this being a user-space problem.

3. The submitter was asked to test a mainline kernel and was not able to do
so. You asked what happened and they replied. You then asked them to
try another mainline kernel. Again, they said they were not able to do
so.

-> Ok.

4. At this point you asked them to start bisecting their kernel. In order
to do so you have to:

1. Believe that it is a kernel bug (which is still not clear from any
of the comments).

-> I had and have a belief that it may be, not is, a kernel bug. The results of the bisect will better reflect how correct the belief is, and move the bug forward.

2. Have a "good kernel" starting point and a "bad kernel" starting
point.

-> Due to the above agreed upon ambiguity, and contradictory information from:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997767/comments/79

good natty, bad precise.

If you were to do the bisection yourself, what would _you_ use for
those two tags to diagnose this bug?

-> precise regression-release needs-bisect

5. Your comment #78 says: "The next step is to perform a bisect to identify
the offending commit(s). Could you please do so following
https://wiki.ubuntu.com/Kernel/KernelBisection ?" And you set the status
of the bug to "Incomplete".

This sounds exactly like you telling the user to go bisect the kernel
and come back when they are done.

-> Again, I _asked_ them to do so, not told them. Asking, as opposed to telling, is a big difference. Despite the potential user space problem, if the reporter is comfortable with bisecting it would be nice for them to do this to clear up the ambiguity of this being a user-space v. kernel bug.

In conclusion, I stand by everything in my comment.

-> That is unfortunate. Despite this, you did not address all of my inquiries.
First, how it's better to let the reporter decide if they can, or cannot bisect, independent of the ambiguity of evidence being a kernel bug. As per:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997767/comments/79
"I can try to bisect..."

the reporter was willing to try. Your response:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997767/comments/80
"Many people just are not prepared to do so."

is still arbitrary, in light of clear and unarguable evidence to contradict your position. I think your belief that reporters shouldn't be asked to bisect, because they may or may not be prepared, goes against progressing bugs forward to Triaged, and ultimately Fix Released.

Second, what do you, or anyone else think would have been the ideal response to better tease out the true root cause?

In summary, I stand by my request for a bisect and initiating thread points.

Thank you for your time and consideration in this matter and I look forward to your response.

> --
> Christopher M. Penalver
> E-Mail: christopher.penalver@gmx.com
> MCSE:Security, MCSA, MCDST, MCP, Security+, Network+, A+, NSSP
>
> This E-Mail was sent via a laptop using Xubuntu, Linux for human beings.
> www.xubuntu.org
> http://www.launchpad.net/~penalvch
> Acer Aspire 5750-9668 Xubuntu 12.04
>
>
>
>

Brad
--
Brad Figg brad.figg@canonical.com http://www.canonical.com
*



--
Christopher*M.*Penalver
E-Mail:*christopher.penalver@gmx.com
MCSE:Security,*MCSA,*MCDST,*MCP,*Security+,*Networ k+,*A+,*NSSP

This*E-Mail*was*sent*via*a*laptop*using*Xubuntu,*Linux*fo r*human*beings.
www.xubuntu.org
http://www.launchpad.net/~penalvch
Acer*Aspire*5750-9668*Xubuntu*12.04

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 11:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org