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 11-12-2010, 01:36 PM
David Henningsson
 
Default The new drop-my-patch policy

I have the following issues with the new drop-my-patch policy:

* First, and this is likely a bug, it seems to send out a threat emails
even to fixes that come from upstream stable. For an example, see bug
#640254.

* Second, I'm less likely to want to submit fixes to the Ubuntu kernel,
as I usually don't have access to the hardware. If I fix a bug, I don't
know if the user having the bug is even logged in within the next six
days. So I will now take a large risk of having my work being done in
vain, just because I don't know when the user will test my patch.
I could go via stable@kernel.org instead, but that will leave the user
waiting for longer times - and it's not even an option for Maverick, as
2.6.35 is no longer maintained.

* Third, I don't think it's in line with the Ubuntu spirit and policy of
"Just works" and "Humanity to others" to let a bot drop their precious
fixes, if the tester does not fill in the bureaucracy correctly (e g
reporting back that it works but forgets to change the tag). At the very
least we should offer a way to get the patch resent and retested.

* Fourth, I assume the original motivation for having the drop-my-patch
policy is to reduce regression risk. But do we really know how much of
regressions actually come from Ubuntu-only patches?

So far I think the drop-my-patch policy adds bureaucracy, and reduces
willingness to contribute. In turn, this will reduce the quality of the
Ubuntu kernel.

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-12-2010, 03:33 PM
Brad Figg
 
Default The new drop-my-patch policy

On 11/12/2010 06:36 AM, David Henningsson wrote:
> I have the following issues with the new drop-my-patch policy:
>
> * First, and this is likely a bug, it seems to send out a threat emails
> even to fixes that come from upstream stable. For an example, see bug
> #640254.
>

Yes, this should not have happened for this bug.

> * Second, I'm less likely to want to submit fixes to the Ubuntu kernel,
> as I usually don't have access to the hardware. If I fix a bug, I don't
> know if the user having the bug is even logged in within the next six
> days. So I will now take a large risk of having my work being done in
> vain, just because I don't know when the user will test my patch.
> I could go via stable@kernel.org instead, but that will leave the user
> waiting for longer times - and it's not even an option for Maverick, as
> 2.6.35 is no longer maintained.

The policy has always been that patches submitted and accepted via the
SRU policy must be verified fixed in the kernel containing the fix. This
is only relaxed for upstream, stable patches due to their shear number
and the belief that they are getting testing and verification via the
upstream processes.

If you personally are submitting a patch which fixes a bug then you must
either have the HW yourself or be working with a bug submitter that has
the HW. If neither is the case you should not be submitting a patch.

>
> * Third, I don't think it's in line with the Ubuntu spirit and policy of
> "Just works" and "Humanity to others" to let a bot drop their precious
> fixes, if the tester does not fill in the bureaucracy correctly (e g
> reporting back that it works but forgets to change the tag). At the very
> least we should offer a way to get the patch resent and retested.
>

At this point the "bot" is Steve Conklin. Due to the bot being human, it
does occasionally make mistakes. We are still working through the process
of identifying which bugs/commits need to be reverted. Right now this means
visually inspecting every lp bug for a given release.

Because we are looking at the bugs ourselves, we are trying to catch the
cases where a submitter has indicated that they have verified the bug but
forgotten to change the tag.

We are discussing what to do with commits once they have been reverted. One
thought is to automatically reapply them to the next upload so that the
submitter can verify them in the next proposed. NOTE: This is _not_
necessarily what we are going to do, just one of the things we are talking
about.

> * Fourth, I assume the original motivation for having the drop-my-patch
> policy is to reduce regression risk. But do we really know how much of
> regressions actually come from Ubuntu-only patches?
>

Actually, this has always been the SRU policy, it just hasn't been enforced
as strictly for kernel commits as it is now. Do we have actual numbers as to
how many "Ubuntu-only" patches caused regressions. Not that I'm aware of.

> So far I think the drop-my-patch policy adds bureaucracy, and reduces
> willingness to contribute. In turn, this will reduce the quality of the
> Ubuntu kernel.
>

Being asked to verify the patches that you submit is not additional bureaucracy
but is enforcement of existing policy.

--
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 11-15-2010, 06:09 AM
David Henningsson
 
Default The new drop-my-patch policy

On 2010-11-12 17:33, Brad Figg wrote:
> On 11/12/2010 06:36 AM, David Henningsson wrote:
>> I have the following issues with the new drop-my-patch policy:
>>
>> * First, and this is likely a bug, it seems to send out a threat emails
>> even to fixes that come from upstream stable. For an example, see bug
>> #640254.
>>
>
> Yes, this should not have happened for this bug.
>
>> * Second, I'm less likely to want to submit fixes to the Ubuntu kernel,
>> as I usually don't have access to the hardware. If I fix a bug, I don't
>> know if the user having the bug is even logged in within the next six
>> days. So I will now take a large risk of having my work being done in
>> vain, just because I don't know when the user will test my patch.
>> I could go via stable@kernel.org instead, but that will leave the user
>> waiting for longer times - and it's not even an option for Maverick, as
>> 2.6.35 is no longer maintained.
>
> The policy has always been that patches submitted and accepted via the
> SRU policy must be verified fixed in the kernel containing the fix. This
> is only relaxed for upstream, stable patches due to their shear number
> and the belief that they are getting testing and verification via the
> upstream processes.
>
> If you personally are submitting a patch which fixes a bug then you must
> either have the HW yourself or be working with a bug submitter that has
> the HW. If neither is the case you should not be submitting a patch.
>
>>
>> * Third, I don't think it's in line with the Ubuntu spirit and policy of
>> "Just works" and "Humanity to others" to let a bot drop their precious
>> fixes, if the tester does not fill in the bureaucracy correctly (e g
>> reporting back that it works but forgets to change the tag). At the very
>> least we should offer a way to get the patch resent and retested.
>>
>
> At this point the "bot" is Steve Conklin. Due to the bot being human, it
> does occasionally make mistakes. We are still working through the process
> of identifying which bugs/commits need to be reverted. Right now this means
> visually inspecting every lp bug for a given release.
>
> Because we are looking at the bugs ourselves, we are trying to catch the
> cases where a submitter has indicated that they have verified the bug but
> forgotten to change the tag.
>
> We are discussing what to do with commits once they have been reverted. One
> thought is to automatically reapply them to the next upload so that the
> submitter can verify them in the next proposed. NOTE: This is _not_
> necessarily what we are going to do, just one of the things we are talking
> about.

Brad,

thanks for clearing a lot of this up for me.

The reason I believed a bot was auto-reverting stuff was because I asked
this question at the UDS session and got an answer along the lines of
"let the users learn that the hard way".

Whereas the SRU policy is more along the lines of "If an update does not
get any testing/verification feedback for more than half a year, despite
several calls for testing, the Stable Release Managers will remove the
package" rather than dropping after six days, I understand that the
kernel is a special case since it is so big (which in turn could be
questioned, but that's something completely different).

So, given
1) the manual verification of stuff not marked as verification-done,
2) that we have an either automatic, or at least a very easy way, for
the user to request a reapply of the fix for the next proposed kernel,
3) and perhaps rewrite the bot comments according to the "Hi! Many
thanks..." Ubuntu style,
perhaps this policy isn't as user-unfriendly as I first believed.

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 01-13-2011, 05:18 PM
David Henningsson
 
Default The new drop-my-patch policy

On 2010-11-12 10:33, Brad Figg wrote:

On 11/12/2010 06:36 AM, David Henningsson wrote:

I have the following issues with the new drop-my-patch policy:

* First, and this is likely a bug, it seems to send out a threat emails
even to fixes that come from upstream stable. For an example, see bug
#640254.



Yes, this should not have happened for this bug.


This has now happened again for bugs: #690798, #677652, #682199,
#669279, #611803, #656625, #677830, #683695, #497546. (This is a
qualified guess from looking at the changelog for maverick-proposed.)


Are you planning to fix this issue anytime soon?

// David

--
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 02:36 AM.

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