The new drop-my-patch policy

[Brad Figg]

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.

> * 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 at canonical.com http://www.canonical.com