The new drop-my-patch policy

[David Henningsson]

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 at 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