[Meego-kernel] rejects against .35?
Arjan van de Ven
arjan at linux.intel.com
Fri Dec 3 12:10:51 PST 2010
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.
> 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)
More information about the MeeGo-kernel