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

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

[Philippe Gerum]

The I-pipe tree at git://git.xenomai.org/ipipe.git will be reorganized 
today at 3pm GMT. At this chance, support for the 3.8.0 kernel will be 
introduced.

The complete commit history will be preserved, along with existing tags. 
Branches may be renamed though, to better reflect the new development 
workflow introduced with the pipeline "core" series.

If you have scripts pulling from this repository in any automated way, 
you may want to stop them for the day.

A description of the few changes involved will be sent to this mailing 
list later today, shortly before the new repository is published.

Thanks,

-- 
Philippe.

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

[Philippe Gerum]

On 05/27/2013 09:45 AM, Philippe Gerum wrote:
>
> The I-pipe tree at git://git.xenomai.org/ipipe.git will be reorganized
> today at 3pm GMT. At this chance, support for the 3.8.0 kernel will be
> introduced.
>
> The complete commit history will be preserved, along with existing tags.
> Branches may be renamed though, to better reflect the new development
> workflow introduced with the pipeline "core" series.
>
> If you have scripts pulling from this repository in any automated way,
> you may want to stop them for the day.
>
> A description of the few changes involved will be sent to this mailing
> list later today, shortly before the new repository is published.
>

The reshuffled repository is now on line.

The changes are as follows:

- all legacy pipeline branches (i.e. pre-"core" series) have moved under 
the legacy/ hierarchy, e.g.
ipipe-2.6.20-powerpc => legacy/ipipe-2.6.20-powerpc
All branches under legacy/ are frozen, and won't be updated anymore.

- the master branch now reflects the state of the mainline I-pipe 
development. Pull from this branch for the latest validated commits, for 
the latest supported kernel.

- new ipipe-<kernel.version> branches are started off master 
periodically, for maintaining the pipeline over stable kernel releases. 
These branches include the pipeline code for a given kernel release, for 
a set of architectures we support in this release. There is neither 
arch-specific nor -noarch branches anymore.

The former core-<kernel.version> branches are now available as 
legacy/core-<kernel.version>, with ipipe-<stable-kernel-version> 
reflecting the latest stable fixes that were merged into those branches. 
For instance, the former core-3.4 branch can be found as both 
legacy/core-3.4, and ipipe-3.4.6 in the reorganized repository.

- The new ipipe-next branch contains brewing stuff, possibly not fully 
validated on all supported architectures yet. It receives new features 
on their way to master, and arch-specific merges. Unlike other branches, 
ipipe-next may be subject to rebase, prior to merging it into master.

Practically, people who depend on a particular stable kernel version 
should track the corresponding ipipe-<kernel.version> branch.

People working over the bleeding edge tip should rebase over ipipe-next 
periodically.

People who want reasonably validated stuff for the latest kernel release 
we support should track master.

HTH,

-- 
Philippe.

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

[Jan Kiszka]

On 2013-05-27 18:56, Philippe Gerum wrote:
> On 05/27/2013 09:45 AM, Philippe Gerum wrote:
>>
>> The I-pipe tree at git://git.xenomai.org/ipipe.git will be reorganized
>> today at 3pm GMT. At this chance, support for the 3.8.0 kernel will be
>> introduced.
>>
>> The complete commit history will be preserved, along with existing tags.
>> Branches may be renamed though, to better reflect the new development
>> workflow introduced with the pipeline "core" series.
>>
>> If you have scripts pulling from this repository in any automated way,
>> you may want to stop them for the day.
>>
>> A description of the few changes involved will be sent to this mailing
>> list later today, shortly before the new repository is published.
>>
> 
> The reshuffled repository is now on line.
> 
> The changes are as follows:
> 
> - all legacy pipeline branches (i.e. pre-"core" series) have moved under
> the legacy/ hierarchy, e.g.
> ipipe-2.6.20-powerpc => legacy/ipipe-2.6.20-powerpc
> All branches under legacy/ are frozen, and won't be updated anymore.
> 
> - the master branch now reflects the state of the mainline I-pipe
> development. Pull from this branch for the latest validated commits, for
> the latest supported kernel.
> 
> - new ipipe-<kernel.version> branches are started off master
> periodically, for maintaining the pipeline over stable kernel releases.
> These branches include the pipeline code for a given kernel release, for
> a set of architectures we support in this release. There is neither
> arch-specific nor -noarch branches anymore.

Will pulling in stable updates for a kernel major release create new
branches or is "ipipe-3.8.0" a misnomer that should actually be called
"ipipe-3.8"? I'd like to update 3.8 to the final stable release and was
wondering about the best process for this. We will need some core code
patch conflict resolutions that I already done here some time ago.

Jan

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

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

[Philippe Gerum]

On 06/11/2013 01:37 PM, Jan Kiszka wrote:
> On 2013-05-27 18:56, Philippe Gerum wrote:
>> On 05/27/2013 09:45 AM, Philippe Gerum wrote:
>>>
>>> The I-pipe tree at git://git.xenomai.org/ipipe.git will be reorganized
>>> today at 3pm GMT. At this chance, support for the 3.8.0 kernel will be
>>> introduced.
>>>
>>> The complete commit history will be preserved, along with existing tags.
>>> Branches may be renamed though, to better reflect the new development
>>> workflow introduced with the pipeline "core" series.
>>>
>>> If you have scripts pulling from this repository in any automated way,
>>> you may want to stop them for the day.
>>>
>>> A description of the few changes involved will be sent to this mailing
>>> list later today, shortly before the new repository is published.
>>>
>>
>> The reshuffled repository is now on line.
>>
>> The changes are as follows:
>>
>> - all legacy pipeline branches (i.e. pre-"core" series) have moved under
>> the legacy/ hierarchy, e.g.
>> ipipe-2.6.20-powerpc => legacy/ipipe-2.6.20-powerpc
>> All branches under legacy/ are frozen, and won't be updated anymore.
>>
>> - the master branch now reflects the state of the mainline I-pipe
>> development. Pull from this branch for the latest validated commits, for
>> the latest supported kernel.
>>
>> - new ipipe-<kernel.version> branches are started off master
>> periodically, for maintaining the pipeline over stable kernel releases.
>> These branches include the pipeline code for a given kernel release, for
>> a set of architectures we support in this release. There is neither
>> arch-specific nor -noarch branches anymore.
>
> Will pulling in stable updates for a kernel major release create new
> branches

ipipe-3.8.0 is actually checkout -b from master prior to working on a 
more recent release in ipipe-next. This is really for 3.8.0 material only.

  or is "ipipe-3.8.0" a misnomer that should actually be called
> "ipipe-3.8"? I'd like to update 3.8 to the final stable release and was
> wondering about the best process for this. We will need some core code
> patch conflict resolutions that I already done here some time ago.
>
> Jan
>


-- 
Philippe.

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

[Jan Kiszka]

On 2013-06-11 15:22, Philippe Gerum wrote:
> On 06/11/2013 01:37 PM, Jan Kiszka wrote:
>> On 2013-05-27 18:56, Philippe Gerum wrote:
>>> On 05/27/2013 09:45 AM, Philippe Gerum wrote:
>>>>
>>>> The I-pipe tree at git://git.xenomai.org/ipipe.git will be reorganized
>>>> today at 3pm GMT. At this chance, support for the 3.8.0 kernel will be
>>>> introduced.
>>>>
>>>> The complete commit history will be preserved, along with existing tags.
>>>> Branches may be renamed though, to better reflect the new development
>>>> workflow introduced with the pipeline "core" series.
>>>>
>>>> If you have scripts pulling from this repository in any automated way,
>>>> you may want to stop them for the day.
>>>>
>>>> A description of the few changes involved will be sent to this mailing
>>>> list later today, shortly before the new repository is published.
>>>>
>>>
>>> The reshuffled repository is now on line.
>>>
>>> The changes are as follows:
>>>
>>> - all legacy pipeline branches (i.e. pre-"core" series) have moved under
>>> the legacy/ hierarchy, e.g.
>>> ipipe-2.6.20-powerpc => legacy/ipipe-2.6.20-powerpc
>>> All branches under legacy/ are frozen, and won't be updated anymore.
>>>
>>> - the master branch now reflects the state of the mainline I-pipe
>>> development. Pull from this branch for the latest validated commits, for
>>> the latest supported kernel.
>>>
>>> - new ipipe-<kernel.version> branches are started off master
>>> periodically, for maintaining the pipeline over stable kernel releases.
>>> These branches include the pipeline code for a given kernel release, for
>>> a set of architectures we support in this release. There is neither
>>> arch-specific nor -noarch branches anymore.
>>
>> Will pulling in stable updates for a kernel major release create new
>> branches
> 
> ipipe-3.8.0 is actually checkout -b from master prior to working on a 
> more recent release in ipipe-next. This is really for 3.8.0 material only.

So where should the 3.8.13 merge go to?

Jan

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

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

[Philippe Gerum]

On 06/11/2013 03:31 PM, Jan Kiszka wrote:
> On 2013-06-11 15:22, Philippe Gerum wrote:
>> On 06/11/2013 01:37 PM, Jan Kiszka wrote:
>>> On 2013-05-27 18:56, Philippe Gerum wrote:
>>>> On 05/27/2013 09:45 AM, Philippe Gerum wrote:
>>>>>
>>>>> The I-pipe tree at git://git.xenomai.org/ipipe.git will be reorganized
>>>>> today at 3pm GMT. At this chance, support for the 3.8.0 kernel will be
>>>>> introduced.
>>>>>
>>>>> The complete commit history will be preserved, along with existing tags.
>>>>> Branches may be renamed though, to better reflect the new development
>>>>> workflow introduced with the pipeline "core" series.
>>>>>
>>>>> If you have scripts pulling from this repository in any automated way,
>>>>> you may want to stop them for the day.
>>>>>
>>>>> A description of the few changes involved will be sent to this mailing
>>>>> list later today, shortly before the new repository is published.
>>>>>
>>>>
>>>> The reshuffled repository is now on line.
>>>>
>>>> The changes are as follows:
>>>>
>>>> - all legacy pipeline branches (i.e. pre-"core" series) have moved under
>>>> the legacy/ hierarchy, e.g.
>>>> ipipe-2.6.20-powerpc => legacy/ipipe-2.6.20-powerpc
>>>> All branches under legacy/ are frozen, and won't be updated anymore.
>>>>
>>>> - the master branch now reflects the state of the mainline I-pipe
>>>> development. Pull from this branch for the latest validated commits, for
>>>> the latest supported kernel.
>>>>
>>>> - new ipipe-<kernel.version> branches are started off master
>>>> periodically, for maintaining the pipeline over stable kernel releases.
>>>> These branches include the pipeline code for a given kernel release, for
>>>> a set of architectures we support in this release. There is neither
>>>> arch-specific nor -noarch branches anymore.
>>>
>>> Will pulling in stable updates for a kernel major release create new
>>> branches
>>
>> ipipe-3.8.0 is actually checkout -b from master prior to working on a
>> more recent release in ipipe-next. This is really for 3.8.0 material only.
>
> So where should the 3.8.13 merge go to?
>

It would first have to go through ipipe-next, then master when ready for 
all archs.


-- 
Philippe.

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

[Jan Kiszka]

On 2013-06-11 16:01, Philippe Gerum wrote:
> On 06/11/2013 03:31 PM, Jan Kiszka wrote:
>> On 2013-06-11 15:22, Philippe Gerum wrote:
>>> On 06/11/2013 01:37 PM, Jan Kiszka wrote:
>>>> On 2013-05-27 18:56, Philippe Gerum wrote:
>>>>> On 05/27/2013 09:45 AM, Philippe Gerum wrote:
>>>>>>
>>>>>> The I-pipe tree at git://git.xenomai.org/ipipe.git will be reorganized
>>>>>> today at 3pm GMT. At this chance, support for the 3.8.0 kernel will be
>>>>>> introduced.
>>>>>>
>>>>>> The complete commit history will be preserved, along with existing tags.
>>>>>> Branches may be renamed though, to better reflect the new development
>>>>>> workflow introduced with the pipeline "core" series.
>>>>>>
>>>>>> If you have scripts pulling from this repository in any automated way,
>>>>>> you may want to stop them for the day.
>>>>>>
>>>>>> A description of the few changes involved will be sent to this mailing
>>>>>> list later today, shortly before the new repository is published.
>>>>>>
>>>>>
>>>>> The reshuffled repository is now on line.
>>>>>
>>>>> The changes are as follows:
>>>>>
>>>>> - all legacy pipeline branches (i.e. pre-"core" series) have moved under
>>>>> the legacy/ hierarchy, e.g.
>>>>> ipipe-2.6.20-powerpc => legacy/ipipe-2.6.20-powerpc
>>>>> All branches under legacy/ are frozen, and won't be updated anymore.
>>>>>
>>>>> - the master branch now reflects the state of the mainline I-pipe
>>>>> development. Pull from this branch for the latest validated commits, for
>>>>> the latest supported kernel.
>>>>>
>>>>> - new ipipe-<kernel.version> branches are started off master
>>>>> periodically, for maintaining the pipeline over stable kernel releases.
>>>>> These branches include the pipeline code for a given kernel release, for
>>>>> a set of architectures we support in this release. There is neither
>>>>> arch-specific nor -noarch branches anymore.
>>>>
>>>> Will pulling in stable updates for a kernel major release create new
>>>> branches
>>>
>>> ipipe-3.8.0 is actually checkout -b from master prior to working on a
>>> more recent release in ipipe-next. This is really for 3.8.0 material only.
>>
>> So where should the 3.8.13 merge go to?
>>
> 
> It would first have to go through ipipe-next, then master when ready for 
> all archs.

That makes no sense. Master just happens to still point to 3.8, but it
may have already moved on to 3.9 or higher. So stable merges must work
against the stable forks, no?

FWIW, I've merged it into ipipe-3.8.0 now. Will push it soon and drop a
note for Gilles to review the arm conflict resolutions I made. Then I
think we could move ipipe-3.8 forward.

Jan

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

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

[Philippe Gerum]

On 06/11/2013 04:06 PM, Jan Kiszka wrote:
> On 2013-06-11 16:01, Philippe Gerum wrote:
>> On 06/11/2013 03:31 PM, Jan Kiszka wrote:
>>> On 2013-06-11 15:22, Philippe Gerum wrote:
>>>> On 06/11/2013 01:37 PM, Jan Kiszka wrote:
>>>>> On 2013-05-27 18:56, Philippe Gerum wrote:
>>>>>> On 05/27/2013 09:45 AM, Philippe Gerum wrote:
>>>>>>>
>>>>>>> The I-pipe tree at git://git.xenomai.org/ipipe.git will be reorganized
>>>>>>> today at 3pm GMT. At this chance, support for the 3.8.0 kernel will be
>>>>>>> introduced.
>>>>>>>
>>>>>>> The complete commit history will be preserved, along with existing tags.
>>>>>>> Branches may be renamed though, to better reflect the new development
>>>>>>> workflow introduced with the pipeline "core" series.
>>>>>>>
>>>>>>> If you have scripts pulling from this repository in any automated way,
>>>>>>> you may want to stop them for the day.
>>>>>>>
>>>>>>> A description of the few changes involved will be sent to this mailing
>>>>>>> list later today, shortly before the new repository is published.
>>>>>>>
>>>>>>
>>>>>> The reshuffled repository is now on line.
>>>>>>
>>>>>> The changes are as follows:
>>>>>>
>>>>>> - all legacy pipeline branches (i.e. pre-"core" series) have moved under
>>>>>> the legacy/ hierarchy, e.g.
>>>>>> ipipe-2.6.20-powerpc => legacy/ipipe-2.6.20-powerpc
>>>>>> All branches under legacy/ are frozen, and won't be updated anymore.
>>>>>>
>>>>>> - the master branch now reflects the state of the mainline I-pipe
>>>>>> development. Pull from this branch for the latest validated commits, for
>>>>>> the latest supported kernel.
>>>>>>
>>>>>> - new ipipe-<kernel.version> branches are started off master
>>>>>> periodically, for maintaining the pipeline over stable kernel releases.
>>>>>> These branches include the pipeline code for a given kernel release, for
>>>>>> a set of architectures we support in this release. There is neither
>>>>>> arch-specific nor -noarch branches anymore.
>>>>>
>>>>> Will pulling in stable updates for a kernel major release create new
>>>>> branches
>>>>
>>>> ipipe-3.8.0 is actually checkout -b from master prior to working on a
>>>> more recent release in ipipe-next. This is really for 3.8.0 material only.
>>>
>>> So where should the 3.8.13 merge go to?
>>>
>>
>> It would first have to go through ipipe-next, then master when ready for
>> all archs.
>
> That makes no sense. Master just happens to still point to 3.8, but it
> may have already moved on to 3.9 or higher. So stable merges must work
> against the stable forks, no?

Master is our tip, not mainline's. It contains the most recent kernel we 
support I-pipe wise.

>
> FWIW, I've merged it into ipipe-3.8.0 now. Will push it soon and drop a
> note for Gilles to review the arm conflict resolutions I made. Then I
> think we could move ipipe-3.8 forward.
>
> Jan
>


-- 
Philippe.

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

[Jan Kiszka]

On 2013-06-11 16:15, Philippe Gerum wrote:
> On 06/11/2013 04:06 PM, Jan Kiszka wrote:
>> On 2013-06-11 16:01, Philippe Gerum wrote:
>>> On 06/11/2013 03:31 PM, Jan Kiszka wrote:
>>>> On 2013-06-11 15:22, Philippe Gerum wrote:
>>>>> On 06/11/2013 01:37 PM, Jan Kiszka wrote:
>>>>>> On 2013-05-27 18:56, Philippe Gerum wrote:
>>>>>>> On 05/27/2013 09:45 AM, Philippe Gerum wrote:
>>>>>>>>
>>>>>>>> The I-pipe tree at git://git.xenomai.org/ipipe.git will be reorganized
>>>>>>>> today at 3pm GMT. At this chance, support for the 3.8.0 kernel will be
>>>>>>>> introduced.
>>>>>>>>
>>>>>>>> The complete commit history will be preserved, along with existing tags.
>>>>>>>> Branches may be renamed though, to better reflect the new development
>>>>>>>> workflow introduced with the pipeline "core" series.
>>>>>>>>
>>>>>>>> If you have scripts pulling from this repository in any automated way,
>>>>>>>> you may want to stop them for the day.
>>>>>>>>
>>>>>>>> A description of the few changes involved will be sent to this mailing
>>>>>>>> list later today, shortly before the new repository is published.
>>>>>>>>
>>>>>>>
>>>>>>> The reshuffled repository is now on line.
>>>>>>>
>>>>>>> The changes are as follows:
>>>>>>>
>>>>>>> - all legacy pipeline branches (i.e. pre-"core" series) have moved under
>>>>>>> the legacy/ hierarchy, e.g.
>>>>>>> ipipe-2.6.20-powerpc => legacy/ipipe-2.6.20-powerpc
>>>>>>> All branches under legacy/ are frozen, and won't be updated anymore.
>>>>>>>
>>>>>>> - the master branch now reflects the state of the mainline I-pipe
>>>>>>> development. Pull from this branch for the latest validated commits, for
>>>>>>> the latest supported kernel.
>>>>>>>
>>>>>>> - new ipipe-<kernel.version> branches are started off master
>>>>>>> periodically, for maintaining the pipeline over stable kernel releases.
>>>>>>> These branches include the pipeline code for a given kernel release, for
>>>>>>> a set of architectures we support in this release. There is neither
>>>>>>> arch-specific nor -noarch branches anymore.
>>>>>>
>>>>>> Will pulling in stable updates for a kernel major release create new
>>>>>> branches
>>>>>
>>>>> ipipe-3.8.0 is actually checkout -b from master prior to working on a
>>>>> more recent release in ipipe-next. This is really for 3.8.0 material only.
>>>>
>>>> So where should the 3.8.13 merge go to?
>>>>
>>>
>>> It would first have to go through ipipe-next, then master when ready for
>>> all archs.
>>
>> That makes no sense. Master just happens to still point to 3.8, but it
>> may have already moved on to 3.9 or higher. So stable merges must work
>> against the stable forks, no?
> 
> Master is our tip, not mainline's. It contains the most recent kernel we 
> support I-pipe wise.

Still, stable patches do not belong into master. It tracks Linus'
master, and some stable patches may not be found identically in Linus'
tree. So they belong into the stable forks.

Jan

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

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

[Philippe Gerum]

On 06/11/2013 04:18 PM, Jan Kiszka wrote:
> On 2013-06-11 16:15, Philippe Gerum wrote:
>> On 06/11/2013 04:06 PM, Jan Kiszka wrote:
>>> On 2013-06-11 16:01, Philippe Gerum wrote:
>>>> On 06/11/2013 03:31 PM, Jan Kiszka wrote:
>>>>> On 2013-06-11 15:22, Philippe Gerum wrote:
>>>>>> On 06/11/2013 01:37 PM, Jan Kiszka wrote:
>>>>>>> On 2013-05-27 18:56, Philippe Gerum wrote:
>>>>>>>> On 05/27/2013 09:45 AM, Philippe Gerum wrote:
>>>>>>>>>
>>>>>>>>> The I-pipe tree at git://git.xenomai.org/ipipe.git will be reorganized
>>>>>>>>> today at 3pm GMT. At this chance, support for the 3.8.0 kernel will be
>>>>>>>>> introduced.
>>>>>>>>>
>>>>>>>>> The complete commit history will be preserved, along with existing tags.
>>>>>>>>> Branches may be renamed though, to better reflect the new development
>>>>>>>>> workflow introduced with the pipeline "core" series.
>>>>>>>>>
>>>>>>>>> If you have scripts pulling from this repository in any automated way,
>>>>>>>>> you may want to stop them for the day.
>>>>>>>>>
>>>>>>>>> A description of the few changes involved will be sent to this mailing
>>>>>>>>> list later today, shortly before the new repository is published.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The reshuffled repository is now on line.
>>>>>>>>
>>>>>>>> The changes are as follows:
>>>>>>>>
>>>>>>>> - all legacy pipeline branches (i.e. pre-"core" series) have moved under
>>>>>>>> the legacy/ hierarchy, e.g.
>>>>>>>> ipipe-2.6.20-powerpc => legacy/ipipe-2.6.20-powerpc
>>>>>>>> All branches under legacy/ are frozen, and won't be updated anymore.
>>>>>>>>
>>>>>>>> - the master branch now reflects the state of the mainline I-pipe
>>>>>>>> development. Pull from this branch for the latest validated commits, for
>>>>>>>> the latest supported kernel.
>>>>>>>>
>>>>>>>> - new ipipe-<kernel.version> branches are started off master
>>>>>>>> periodically, for maintaining the pipeline over stable kernel releases.
>>>>>>>> These branches include the pipeline code for a given kernel release, for
>>>>>>>> a set of architectures we support in this release. There is neither
>>>>>>>> arch-specific nor -noarch branches anymore.
>>>>>>>
>>>>>>> Will pulling in stable updates for a kernel major release create new
>>>>>>> branches
>>>>>>
>>>>>> ipipe-3.8.0 is actually checkout -b from master prior to working on a
>>>>>> more recent release in ipipe-next. This is really for 3.8.0 material only.
>>>>>
>>>>> So where should the 3.8.13 merge go to?
>>>>>
>>>>
>>>> It would first have to go through ipipe-next, then master when ready for
>>>> all archs.
>>>
>>> That makes no sense. Master just happens to still point to 3.8, but it
>>> may have already moved on to 3.9 or higher. So stable merges must work
>>> against the stable forks, no?
>>
>> Master is our tip, not mainline's. It contains the most recent kernel we
>> support I-pipe wise.
>
> Still, stable patches do not belong into master. It tracks Linus'
> master, and some stable patches may not be found identically in Linus'
> tree. So they belong into the stable forks.
>

There is no requirement to push stable patches back to master. 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.

-- 
Philippe.

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

[Jan Kiszka]

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

If you think we need some ipipe-3.x-next branches as well (as staging
trees for the stable branches), ok. But let's keep things simple first,
I would say. Risk of regressions in stable merges is generally much
lower than in master updates.

Jan

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

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

[Philippe Gerum]

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.

-- 
Philippe.

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

[Jan Kiszka]

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.

Thanks,
Jan

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

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

[Philippe Gerum]

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).

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.

-- 
Philippe.

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

[Jan Kiszka]

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).
> 
> 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.

Jan

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

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

[Jan Kiszka]

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

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

[Philippe Gerum]

On 06/11/2013 06:00 PM, Jan Kiszka wrote:
> 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.
>

Fine by me. Bottom line is that we should have a branch for each stable 
release for which an I-pipe patch has been issued.

-- 
Philippe.

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

[Philippe Gerum]

On 06/11/2013 05:36 PM, 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).
>>
>> 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.

Whether this is right or wrong is another issue, I'm not the one to 
convince about this. Fact is that it happens that way, and often having 
regressions in linux stable should not be a reason for not fixing 
obvious critical I-pipe bugs if this is only about running "git 
cherry-pick".

> If you want to
> maintain outdated stable versions in addition, ok.

There is nothing really complex in pushing I-pipe related critical fixes 
into a stable branch when the opportunity to make things easier 
downstream exists. There should be two, maybe three stable I-pipe 
branches for each 3.x release, each of them exported as a series of 
ipipe-* patches over time. Nobody is volunteering for maintaining each 
and every linux stable release over five years either.

This is just about: we have branched off for issuing an I-pipe patch 
series, we can keep the branch separate in our tree, and try to keep 
that branch (almost) free from any obvious critical I-pipe bug we would 
know about later, likely until the corresponding linux stable tree 
reaches eol.

Bottom line, is that when you run ipipe-foo-3.8.13, then you may assume 
that branch ipipe-3.8.13 exists in our tree.

  But this cannot be
> supported for x86 from our side.
>

I don't see any issue with this.

 > Resources are scarce enough already.

Nah, scarcity starts when you end up writing "from my side", instead of 
"from our side".

-- 
Philippe.

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

[Jan Kiszka]

On 2013-06-11 18:06, Philippe Gerum wrote:
>> If you want to
>> maintain outdated stable versions in addition, ok.
> 
> There is nothing really complex in pushing I-pipe related critical fixes 
> into a stable branch when the opportunity to make things easier 
> downstream exists.

Right. The effort comes from testing all those myriads of combinations.
I'm trying to keep them low for that reason.

Jan

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

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

[Philippe Gerum]

On 06/11/2013 06:05 PM, Jan Kiszka wrote:
> On 2013-06-11 18:06, Philippe Gerum wrote:
>>> If you want to
>>> maintain outdated stable versions in addition, ok.
>>
>> There is nothing really complex in pushing I-pipe related critical fixes
>> into a stable branch when the opportunity to make things easier
>> downstream exists.
>
> Right. The effort comes from testing all those myriads of combinations.
> I'm trying to keep them low for that reason.
>

This is in practice impossible to test all combinations in our context, 
including with deemed latest and greatest releases, so I would not choke 
on this restriction. We have always been in best effort mode. Guaranteed 
mode is for braggart.

-- 
Philippe.

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

[Philippe Gerum]

On 06/11/2013 04:06 PM, Jan Kiszka wrote:
> On 2013-06-11 16:01, Philippe Gerum wrote:
>> On 06/11/2013 03:31 PM, Jan Kiszka wrote:
>>> On 2013-06-11 15:22, Philippe Gerum wrote:
>>>> On 06/11/2013 01:37 PM, Jan Kiszka wrote:
>>>>> On 2013-05-27 18:56, Philippe Gerum wrote:
>>>>>> On 05/27/2013 09:45 AM, Philippe Gerum wrote:
>>>>>>>
>>>>>>> The I-pipe tree at git://git.xenomai.org/ipipe.git will be reorganized
>>>>>>> today at 3pm GMT. At this chance, support for the 3.8.0 kernel will be
>>>>>>> introduced.
>>>>>>>
>>>>>>> The complete commit history will be preserved, along with existing tags.
>>>>>>> Branches may be renamed though, to better reflect the new development
>>>>>>> workflow introduced with the pipeline "core" series.
>>>>>>>
>>>>>>> If you have scripts pulling from this repository in any automated way,
>>>>>>> you may want to stop them for the day.
>>>>>>>
>>>>>>> A description of the few changes involved will be sent to this mailing
>>>>>>> list later today, shortly before the new repository is published.
>>>>>>>
>>>>>>
>>>>>> The reshuffled repository is now on line.
>>>>>>
>>>>>> The changes are as follows:
>>>>>>
>>>>>> - all legacy pipeline branches (i.e. pre-"core" series) have moved under
>>>>>> the legacy/ hierarchy, e.g.
>>>>>> ipipe-2.6.20-powerpc => legacy/ipipe-2.6.20-powerpc
>>>>>> All branches under legacy/ are frozen, and won't be updated anymore.
>>>>>>
>>>>>> - the master branch now reflects the state of the mainline I-pipe
>>>>>> development. Pull from this branch for the latest validated commits, for
>>>>>> the latest supported kernel.
>>>>>>
>>>>>> - new ipipe-<kernel.version> branches are started off master
>>>>>> periodically, for maintaining the pipeline over stable kernel releases.
>>>>>> These branches include the pipeline code for a given kernel release, for
>>>>>> a set of architectures we support in this release. There is neither
>>>>>> arch-specific nor -noarch branches anymore.
>>>>>
>>>>> Will pulling in stable updates for a kernel major release create new
>>>>> branches
>>>>
>>>> ipipe-3.8.0 is actually checkout -b from master prior to working on a
>>>> more recent release in ipipe-next. This is really for 3.8.0 material only.
>>>
>>> So where should the 3.8.13 merge go to?
>>>
>>
>> It would first have to go through ipipe-next, then master when ready for
>> all archs.
>
> That makes no sense. Master just happens to still point to 3.8, but it
> may have already moved on to 3.9 or higher. So stable merges must work
> against the stable forks, no?
>
> FWIW, I've merged it into ipipe-3.8.0 now. Will push it soon and drop a
> note for Gilles to review the arm conflict resolutions I made. Then I
> think we could move ipipe-3.8 forward.
>

Btw, I've started porting to 3.9.4 in the meantime. See 
unstable/ipipe-3.9.4. unstable because it may still contain merge 
conflicts, and very bleeding edge with respect to buildable archs 
anyway. This will move to ipipe-next when the conflicts will have been 
fixed.

-- 
Philippe.