Re: [Xenomai] 3.5.7 "I-pipe: could not find timer" (Was: Re: Kernel OOPS during regression tests)

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2013-01-15 20:39, Gilles Chanteperdrix wrote:
> On 01/15/2013 02:58 PM, Philippe Gerum wrote:
> 
>> On 01/15/2013 02:48 PM, Jan Kiszka wrote:
>>> On 2013-01-15 14:44, Philippe Gerum wrote:
>>>> On 01/15/2013 01:21 PM, Jan Kiszka wrote:
>>>>> On 2013-01-15 13:09, Philippe Gerum wrote:
>>>>>> On 01/15/2013 01:06 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 01/15/2013 12:35 PM, Jan Kiszka wrote:
>>>>>>>
>>>>>>>> On 2013-01-14 21:39, Gilles Chanteperdrix wrote:
>>>>>>>>> Done, also note that my current work is the for-core-3.5.7 branch, not
>>>>>>>>> the for-core-3.5 branch.
>>>>>>>>
>>>>>>>> Both branches point to the same commit ATM. I suppose you didn't push
>>>>>>>> the new for-core-3.5.7 version yet. Once done, I'll rebase my stuff on top.
>>>>>>>
>>>>>>>
>>>>>>> Sorry, pushed.
>>>>>>>
>>>>>>
>>>>>> Please everybody, make sure to eventually resync with my tree, this is
>>>>>> becoming a mess when merging your stuff here. TIA,
>>>>>
>>>>> I'm fetching from you regularly, but your public tree contains no
>>>>> changes for 3.5, sorry.
>>>>>
>>>>
>>>> You must mean no change for 3.5.3 since the last stable pipeline release
>>>> I pushed out. I'm seeing several breakages when merging the very latest
>>>> work, I'm solving this with Gilles.
>>>
>>> I mean that I have no clue what I should resolve. My branch was based on
>>> your core-3.5 branch, the latest publicly available version. I've just
>>> rebased it on top of Gilles' 3.5.7 queue - without any conflicts. So
>>> what are you talking about?
>>>
>>
>> I'm talking about conflicts in pgtable.h, apic.c with the atomic counter 
>> braindamage and stuff like this. I'm not asking you to fix anything in 
>> your tree, I'm pulling from Gilles' trees almost exclusively, and had 
>> issues with those. I raised an alert about painful merges happening 
>> lately, and a recommendation to avoid these. Gilles fixed the issue on 
>> his end, and the merge now resolves as a fast forward, as expected. 
>> Issue closed.
> 
> 
> These were issues due to rebasing. Rebasings makes merging incrementally
> harder, will avoid this in the future.

Rebasing is not bad per se and, where possible, better than leaving an
un-bisectable commit series behind - IMHO. I suppose Philippe started
pulling from your queue before you reordered/updated it again. That's
why I didn't send out a pull request yet - mine wasn't done. I'm trying
to formalize this process here, i.e. never rebase after releasing a
queue for pulling. At the same time, upstream should not pull or pick in
a way that makes life harder for downstream.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux