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 posted a patch some eons back to try and cleanup the patches
in kernel-dev for git to pull in:
http://lists.meego.com/pipermail/meego-kernel/2010-November/001071.html
Dont think anyone was interested..
---
Regards,
Nishanth Menon
_______________________________________________
MeeGo-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel