Re: [Xenomai] git://git.xenomai.org/ipipe.git reshuffle, 3.8.0 kernel support

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

On 2013-06-11 17:36, Jan Kiszka wrote:
> On 2013-06-11 17:33, Philippe Gerum wrote:
>> On 06/11/2013 05:06 PM, Jan Kiszka wrote:
>>> On 2013-06-11 17:05, Philippe Gerum wrote:
>>>> On 06/11/2013 04:56 PM, Jan Kiszka wrote:
>>>>> On 2013-06-11 16:45, Philippe Gerum wrote:
>>>>>> There is no requirement to push stable patches back to master.
>>>>>
>>>>> It makes no sense to push them back, would rather break our model, that
>>>>> is my point.
>>>>>
>>>>>> The only requirement is to branch off master for tracking a stable release.
>>>>>> master is currently 3.8(.0). We'll see how that works. So, 3.8.13 can go
>>>>>> over ipipe-next which is 3.8.10 already, then we may branch off
>>>>>> ipipe-3.8.13 from that head, and switch ipipe-next to 3.9 when we have
>>>>>> something sensible there.
>>>>>
>>>>> So ipipe-next would jump around, at some point tracking master, then
>>>>> again stable - makes no sense. Having multiple ipipe-3.8.x branches
>>>>> makes no sense to me either.
>>>>>
>>>>> Things should work like this:
>>>>>    - master tracks Linus master, thus will never contain any 3.x.y
>>>>>      releases
>>>>>    - ipipe-next is the next master state, but may be thrown away again
>>>>>      due to reworks until it is finally merged into master
>>>>>    - stable branches are forked off from master when it reached a 3.x.0
>>>>>      release point. From then on, fixes to master need to be back-ported
>>>>>      to stable (cherry-picked in the simple case)
>>>>>    - additionally, Linux stable releases are merged into the ipipe stable
>>>>>      branches, resolving conflicts just like we do in master when pulling
>>>>>      Linus changes in
>>>>>
>>>>
>>>> Thanks. You have just summarized what we devised weeks ago with all
>>>> maintainers. We agree on the model, no issue with that. I'm unsure why
>>>> you did not get to that conclusion, but let's move on. This is ok.
>>>
>>> Then please fix the existing branches accordingly, i.e. do not have
>>> 3.8.10 in ipipe-next and rename ipipe-3.8.0 to ipipe-3.8, e.g. when
>>> merging in 3.8.13.
>>>
>>
>> There is a series of patches issued for 3.8.0, so there must be a 3.8.0 
>> branch anyway. Having 3.8.10 in ipipe-next is what seems to be confusing
>> to you; this branch is currently used for holding the hot topic for the 
>> highest release we are actively working on, and this is currently 
>> 3.8.10. Whether this is unfortunate or not, this does make sense to me. 
>> What goes to master has to have gone through ipipe-next, but what's in 
>> ipipe-next does not necessarily goes to master (if it's a stable).

And by the time we will work on both master and a stable version in
parallel, you will see that this model is not really helpful. Please
keep ipipe-next bound to master, also to help observers grasp more
easily what goes on where.

>>
>> ipipe-next should switch to 3.9 in a near future. Not every project may 
>> switch kernels, bumping stable releases, always aiming at the latest 
>> stuff the way you suggest. For these people still restricted to using 
>> e.g. 3.8.4 despite 3.8.13 is out, we keep several stable branches, and 
>> cherry pick critical fixes into them. In that scenario, ipipe-3.8 won't 
>> help.
> 
> I disagree for obvious reasons (security and other bug fixes that enter
> stable trees continuously). Whenever we update a stable ipipe patch, it
> takes _very_ good reasons to _not_ pull in latest stable fixes as well
> and make sure their potential conflicts are resolved. If you want to
> maintain outdated stable versions in addition, ok. But this cannot be
> supported for x86 from our side. Resources are scarce enough already.

So if you really want maintenance for individual stable versions, lets
fork off some ipipe-3.8.0 from a ipipe-3.8 when such a scenario becomes
real. This way, ipipe-3.x will always point to the combination of latest
stable kernel + latest stable ipipe.

Jan

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