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)
_______________________________________________
MeeGo-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel
