[OE-core] Missing Patch Headers

[Bruce Ashfield]

On Mon, Jun 11, 2012 at 12:44 PM, Saul Wold <sgw at linux.intel.com> wrote:
> On 06/11/2012 08:34 AM, Bruce Ashfield wrote:
>>
>> On Mon, Jun 11, 2012 at 11:23 AM, Saul Wold<sgw at linux.intel.com>  wrote:
>>>
>>>
>>> Folks,
>>>
>>> We recently had a spat of new patches added without patch headers, ie no
>>> patch comment, Signed-off-by or Upstream-Status.
>>>
>>> Please review this list and update the patch and submit a new commit.
>>>
>>> Zhai Edwin -
>>> meta/recipes-graphics/pango/pango-1.28.4/multilib-fix-clean.patch
>>> Laurentiu Palcu -
>>>
>>> meta/recipes-graphics/directfb/directfb/libdirect-remove-include-of-linux-config.h.patch
>>> Cristian Iorga -
>>> meta/recipes-extended/ltp/ltp/fix_building_fom_archive.patch
>>> Xiaofeng Yan - meta/recipes-extended/lsb/lsbinitscripts/functions.patch
>>> Mark Hatle -
>>> meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch
>>> Mark Hatle - meta/recipes-devtools/rpm/rpm/rpm-resolvedep.patch
>>> Andreas Müller -
>>>
>>> meta/recipes-kernel/systemtap/systemtap/runtime-staprun-configure.ac-support-without-nss-for.patch
>>> Bruce Ashfield -
>>>
>>> meta/recipes-kernel/lttng-2.0/lttng-modules/lttng-sycalls-protect-is_compat_task-from-redefiniti.patch
>>
>>
>> Your script is wrong here. That patch has everything you'd expect,
>> since it follows kernel
>> patch conventions. Subject, shortlog, log log and sign-off.
>>
>> So don't expect any resubmission from me on this one, since I won't be
>> putting an upstream
>> status directly in the patch.
>>
> This is a patch in OE-Core, not in the kernel, there is no reason you can't
> update this patch to include the Upstream-Status:? What is the status of
> this patch anyway?  Is it a backport?

It's still patching kernel code, that's always been the distinction we've drawn.
Simply because it is being pushed (temporarily) via quilt or sits out of tree
for a time, doesn't change the fact that if the patch is merged into the kernel
tree, you'd have to strip those parts of the commit/header.

I've always said that kernel patches would follow korg guidelines. That's the
same reason why you don't see any YOCTO or other bug tracking information
within the kernel patches.  I've been consistent in this request since
the dawn of
time :)

It seems to me that you are asking for the patch on disk:

    meta/recipes-kernel/lttng-2.0/lttng-modules/lttng-sycalls-protect-is_compat_task-from-redefiniti.patch

To be modified with that information .. which isn't what I'd want to
do. If we want
to track that, it can be tracked as part of the commit to oe-core, but
not in the
patch itself.

As for whether or not is upstream or not and the compatibility, it was captured
as part of the commit to oe-core:

    lttng-modules: fix compliation error with 3.2.x -stable kernels

The point is taken that the information should be standardized, and
that this patch
falls into a grey area. That original commit header should have used
better language
to track the status, but I recall there being quite the rush to get it fixed.

We need some flexibility in the tracking, since there is no such thing
as one size
fits all, since everything is tracked in a SCM, putting the
information within the SCM
itself is a valid option (and what I'm suggesting here).

The lttng2 modules need a complete refresh and rework, which will happen
against the 3.4 kernel, so this will be fixed as part of that effort.

Cheers,

Bruce


>
> Sau!
>
>
>
>
>> Bruce
>>
>>>
>>>
>>> Thanks
>>> --
>>>    Sau!
>>>
>>> Saul Wold
>>> Yocto Component Wrangler @ Intel
>>> Yocto Project / Poky Build System
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core at lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>>
>>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"