[Meego-kernel] rejects against .35?

[Arjan van de Ven]

On 12/3/2010 11:36 AM, Nishanth Menon wrote:
> Arjan van de Ven had written, on 12/03/2010 12:48 PM, the following:
> [..]
>> since MeeGo is not a development target, the last is not a MeeGo 
>> problem. MeeGo is for INTEGRATION of mature code.
>>
>> MeeGo does keep history, but it keeps the history of the *patches*, 
>> not if the code. This is the very fundamental difference of 
>> INTEGRATION versus DEVELOPMENT.
>>
>> Lets take the eMMC change. That is an upstream backport, and thus has 
>> to be done first in the series (so that when we rebase to a new 
>> kernel, we can just drop the top X patches).... and to be closer to 
>> upstream code level
>> at the time of doing the backport. You can't really do it later in 
>> the series.
> [...]
>
> Your point is valid, BUT, we have a quality standard for the patches 
> on MeeGo.
> http://wiki.meego.com/MeeGo_kernel_documentation_for_contributors#Requesting_a_patch_from_Linus.27_kernel.2C_or_a_maintainer_tree_to_be_integrated_into_MeeGo 
>
> quote:"For either case, we expect you to do the same diligence you do 
> when you send a patch to the Linux Kernel Mailing List: You provide a 
> description of the what and the why, you format the patch in the LKML 
> form (included Signed-off-by: line etc etc)."
>
> My vote goes with maintaining  patches in the OBS repo which keep to 
> kernel standards of patches  -e.g. scripts/checkpatch.pl --strict 
> should report 0 warnings/errors, as of today, for e.g:
> scripts/checkpatch.pl --strict ~/Src/Meego/devel\:kernel/kernel/*.patch
> gives me the following warnings:
> http://pastebin.mozilla.org/874556 (truncated ofcourse).. Makes me 
> wonder if we do keep to the requirement we state for ourselves?
>
> For e.g, I pos


you're absolutely right
I'll spend some time next week to drop a bunch of violating patches (and 
patches that depend on them)