[OE-core] [PATCH v2 04/15] file: replace obsolete automake macros with working ones

Marko Lindqvist cazfi74 at gmail.com
Mon Jan 7 16:26:09 UTC 2013


On 7 January 2013 17:58, Otavio Salvador <otavio at ossystems.com.br> wrote:
> On Mon, Jan 7, 2013 at 11:46 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>> On Mon, 2013-01-07 at 10:18 -0200, Otavio Salvador wrote:
>>> On Mon, Jan 7, 2013 at 10:16 AM, Burton, Ross <ross.burton at intel.com> wrote:
>>> > On 7 January 2013 12:11, Marko Lindqvist <cazfi74 at gmail.com> wrote:
>>> >> What's the correct status for fixes that are not really backports,
>>> >> but have happened independently in oe and upstream?
>>> >>  - If practically identical, still mark as "Backport"?
>>> >>  - If different solution, "Inappropriate [not needed]"?
>>> >
>>> > If you did it and then later discovered it's happened upstream
>>> > independently, it's essentially a backport.
>>
>> The best thing is to consider how we use the information. I'd happily
>> accept "Backport" in this case as meaning "the upstream latest version
>> has equivalent functionality". You can note the status after the word to
>> give specifics if needed.
>>
>>> Maybe it'd be better to not patch at all and update to the newer
>>> recipe version?
>>
>> I don't think that is a reasonable policy in all cases. I'm not going to
>> block automake on all upstreams making new releases for example.
>
> Sure but if there're a new release with the fix it is better to
> upgrade than backport the fix (with exceptions, of course).
>
> My point is: it is good to verify if there're a new release and use it
> if possible. Otherwise backport the fix.

 That's what I'm being doing. Even if new upstream release doesn't
have fix for the particular problem, I try to update to it first.
Rationale being that if update is going to happen at some point
anyway, it's less work to do it without need to update the bugfix to
apply to new version. That is: total work of "update + fix" vs "fix +
update + port the fix".


 - ML




More information about the Openembedded-core mailing list