[Maverick SRU] [PATCH]: Acer aspire 7736 - Playback not working

[Stefan Bader]

On 11/12/2010 10:12 AM, David Henningsson wrote:
> On 2010-11-11 19:19, Leann Ogasawara wrote:
>> On Thu, 2010-11-11 at 11:16 +0100, David Henningsson wrote:
>>> BugLink: https://launchpad.net/bugs/617647
>>>
>>> SRU Justification:
>>>
>>> Impact: A regression in Maverick caused audio playback to stop working
>>> on Acer aspire 7736.
>>>
>>> Fix: Require some new low-impact quirk infrastructure plus the actual quirk.
>>>
>>> Testcase: Try playing back through internal speakers and headphones on
>>> the machine.
>>>
>>> Both patches has been accepted upstream (as commits 90622917 and
>>> c3d226ab) but it does not make sense to send to stable at kernel.org since
>>> 2.6.35 isn't maintained anymore.
>>
>> Looks reasonable and there is positive test confirmation in the bug
>> report.  Only minor nit picks would be that I'd also add the BugLink to
>> Patch 1/2 and I'd also add references to the upstream commits in both
>> patches.  But I'll leave it to Brad/Steve to decide if they want to fix
>> that up by hand when applying.
>>
>> Acked-by: Leann Ogasawara<leann.ogasawara at canonical.com>
>>
> 
> How about then I'll instead ask you to cherrypick commits 90622917 and
> c3d226ab from linux-2.6? That way you'll get upstream references 
> automatically, I assume.
> 
But still would then miss your s-o-b for the sru (to document who submitted it
for that). It is quite similar to what you would do for submitting stable
patches to Greg. He also wants a "commit <sha1> upstream" added to the patch.
For our srus you alternatively could extend the s-o-b area by

(cherry-picked from <sha1> upstream)
Signed-of-by: <you>

> As for the buglink, I don't agree - you have the buglink in the second 
> one only (both in c3d226ab and in the patch posted), which should be 
> correct. That way you don't risk the bug appear to be fixed by only 
> applying the first one by mistake. (And for the sake of argument, the 
> second one won't even apply, or at least not build, without the first 
> one, so if you do the mistake the other way, you'll find it.)
> 
No it isn't. All patches added for SRU need to reference the bug for which they
are needed. Duplicates are allowed and ok. But the SRU team will usually reject
updates when they contain patches without reference. And they are not keen on
reading patches to find out about any dependencies.

-Stefan