[Xenomai] [RFC] FOSDEM meeting agenda

[Xenomai] [RFC] FOSDEM meeting agenda

[Philippe Gerum]

Here are some points I would like to discuss during this meeting. Please
feel free to comment:

1. Release management

	* Currently, the person who contributes most of the code is also the
release manager, which is clearly not optimal. Both activities should be
decoupled for efficiency (esp. hindsight) and practical reasons. At some
point, I will stop acting as the release manager, so the project will
need a different organization in this respect. Which one?

	* As a corollary, the current release process is broken: no explicit
release plan or schedule, limited testing, barely any user feedback
about the development version in general. Practical steps to improve
this should be discussed.

	* My understanding is that v3.1 is almost there feature-wise, with a
working arm64 port Dmitriy is polishing, a bunch of rtnet fixes actually
enabling RTnet with SMAP/x86 (which still need some feedback btw), and
support for recent kernels up to 4.14 (arm, arm64, powerpc). x86 is
still lagging behind with kernel 4.9 though. I'm about to queue a couple
of ABI changes more, with the implementation of sendmmsg() and
recvmmsg() for RTDM sockets.

This raises the following questions: 1) may we freeze the v3.1 ABI, 2)
should we wait for supporting 4.14/x86 before releasing v3.1, 3) how
much use/testing do we currently have of the -next branch, on which CPU
architecture(s)?

2. Documentation

	* The existing documentation has several weaknesses; from the traffic
on the mailing list, the main one may be that it leaves newcomers with a
steep learning curve, in some occasions, even when the information is
published on the website and/or present in the inline documentation. How
to improve the situation, how to better organize the existing doc so
that people do find what they are looking for?

	* Doxygen may not be the best option anymore for inline documentation;
Chasing glitches with using the markup has been a real pain over the
years, getting properly structured output has never been obvious. Could
we do better with Doxygen in a reasonably simple fashion, or should
reStructuredText and Sphinx be considered as a replacement, so that we
can converge toward the kernel documentation system?

3. Pipeline maintenance

	* We now have a dedicated I-pipe maintainer per CPU architecture, which
is a great relief to me. Now I'd like we discuss the maintenance
process, 1) how to organize the upstream/downstream flow of the generic
pipeline bits I still maintain currently, between other maintainers and
me? 2) how to best disseminate knowledge about the I-pipe implementation?

	* mainline vs CIP kernel, LTS maintenance policy

4. Misc

	* formalizing the decision about dropping the blackfin and powerpc64
port, since we had zero feedback from users so far, so everyone must be
fine with this.

Thanks,

-- 
Philippe.

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Jan Kiszka]

On 2018-01-25 18:40, Philippe Gerum wrote:
> 
> Here are some points I would like to discuss during this meeting. Please
> feel free to comment:
> 
> 1. Release management
> 
> 	* Currently, the person who contributes most of the code is also the
> release manager, which is clearly not optimal. Both activities should be
> decoupled for efficiency (esp. hindsight) and practical reasons. At some
> point, I will stop acting as the release manager, so the project will
> need a different organization in this respect. Which one?
> 
> 	* As a corollary, the current release process is broken: no explicit
> release plan or schedule, limited testing, barely any user feedback
> about the development version in general. Practical steps to improve
> this should be discussed.
> 
> 	* My understanding is that v3.1 is almost there feature-wise, with a
> working arm64 port Dmitriy is polishing, a bunch of rtnet fixes actually
> enabling RTnet with SMAP/x86 (which still need some feedback btw), and
> support for recent kernels up to 4.14 (arm, arm64, powerpc). x86 is
> still lagging behind with kernel 4.9 though. I'm about to queue a couple
> of ABI changes more, with the implementation of sendmmsg() and
> recvmmsg() for RTDM sockets.
> 
> This raises the following questions: 1) may we freeze the v3.1 ABI, 2)
> should we wait for supporting 4.14/x86 before releasing v3.1, 3) how
> much use/testing do we currently have of the -next branch, on which CPU
> architecture(s)?
> 
> 2. Documentation
> 
> 	* The existing documentation has several weaknesses; from the traffic
> on the mailing list, the main one may be that it leaves newcomers with a
> steep learning curve, in some occasions, even when the information is
> published on the website and/or present in the inline documentation. How
> to improve the situation, how to better organize the existing doc so
> that people do find what they are looking for?
> 
> 	* Doxygen may not be the best option anymore for inline documentation;
> Chasing glitches with using the markup has been a real pain over the
> years, getting properly structured output has never been obvious. Could
> we do better with Doxygen in a reasonably simple fashion, or should
> reStructuredText and Sphinx be considered as a replacement, so that we
> can converge toward the kernel documentation system?
> 
> 3. Pipeline maintenance
> 
> 	* We now have a dedicated I-pipe maintainer per CPU architecture, which
> is a great relief to me. Now I'd like we discuss the maintenance
> process, 1) how to organize the upstream/downstream flow of the generic
> pipeline bits I still maintain currently, between other maintainers and
> me? 2) how to best disseminate knowledge about the I-pipe implementation?
> 
> 	* mainline vs CIP kernel, LTS maintenance policy
> 
> 4. Misc
> 
> 	* formalizing the decision about dropping the blackfin and powerpc64
> port, since we had zero feedback from users so far, so everyone must be
> fine with this.
> 
> Thanks,
> 

Thanks for preparing this. Sounds good to me.

Adding from Greg's points as well, we probably need to bring up bug
tracking together with the bigger topic workflow and related tooling.
This may easily make us run out of time, but a survey of opinions and
ideas in that round would be good to follow up on the list afterwards.

Then testing. I would also not go into too much details, but it would be
good to understand what exist(ed) and what could be done easily to
improve it. Overlaps also with release management and with the good
proposal to define reference boards.

How many days will our meeting have? ;)

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Greg Gallagher]

We can add an ELC meeting ;)

On Fri, Jan 26, 2018 at 1:49 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2018-01-25 18:40, Philippe Gerum wrote:
>>
>> Here are some points I would like to discuss during this meeting. Please
>> feel free to comment:
>>
>> 1. Release management
>>
>>       * Currently, the person who contributes most of the code is also the
>> release manager, which is clearly not optimal. Both activities should be
>> decoupled for efficiency (esp. hindsight) and practical reasons. At some
>> point, I will stop acting as the release manager, so the project will
>> need a different organization in this respect. Which one?
>>
>>       * As a corollary, the current release process is broken: no explicit
>> release plan or schedule, limited testing, barely any user feedback
>> about the development version in general. Practical steps to improve
>> this should be discussed.
>>
>>       * My understanding is that v3.1 is almost there feature-wise, with a
>> working arm64 port Dmitriy is polishing, a bunch of rtnet fixes actually
>> enabling RTnet with SMAP/x86 (which still need some feedback btw), and
>> support for recent kernels up to 4.14 (arm, arm64, powerpc). x86 is
>> still lagging behind with kernel 4.9 though. I'm about to queue a couple
>> of ABI changes more, with the implementation of sendmmsg() and
>> recvmmsg() for RTDM sockets.
>>
>> This raises the following questions: 1) may we freeze the v3.1 ABI, 2)
>> should we wait for supporting 4.14/x86 before releasing v3.1, 3) how
>> much use/testing do we currently have of the -next branch, on which CPU
>> architecture(s)?
>>
>> 2. Documentation
>>
>>       * The existing documentation has several weaknesses; from the traffic
>> on the mailing list, the main one may be that it leaves newcomers with a
>> steep learning curve, in some occasions, even when the information is
>> published on the website and/or present in the inline documentation. How
>> to improve the situation, how to better organize the existing doc so
>> that people do find what they are looking for?
>>
>>       * Doxygen may not be the best option anymore for inline documentation;
>> Chasing glitches with using the markup has been a real pain over the
>> years, getting properly structured output has never been obvious. Could
>> we do better with Doxygen in a reasonably simple fashion, or should
>> reStructuredText and Sphinx be considered as a replacement, so that we
>> can converge toward the kernel documentation system?
>>
>> 3. Pipeline maintenance
>>
>>       * We now have a dedicated I-pipe maintainer per CPU architecture, which
>> is a great relief to me. Now I'd like we discuss the maintenance
>> process, 1) how to organize the upstream/downstream flow of the generic
>> pipeline bits I still maintain currently, between other maintainers and
>> me? 2) how to best disseminate knowledge about the I-pipe implementation?
>>
>>       * mainline vs CIP kernel, LTS maintenance policy
>>
>> 4. Misc
>>
>>       * formalizing the decision about dropping the blackfin and powerpc64
>> port, since we had zero feedback from users so far, so everyone must be
>> fine with this.
>>
>> Thanks,
>>
>
> Thanks for preparing this. Sounds good to me.
>
> Adding from Greg's points as well, we probably need to bring up bug
> tracking together with the bigger topic workflow and related tooling.
> This may easily make us run out of time, but a survey of opinions and
> ideas in that round would be good to follow up on the list afterwards.
>
> Then testing. I would also not go into too much details, but it would be
> good to understand what exist(ed) and what could be done easily to
> improve it. Overlaps also with release management and with the good
> proposal to define reference boards.
>
> How many days will our meeting have? ;)
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Jan Kiszka]

On 2018-01-26 19:51, Greg Gallagher wrote:
> We can add an ELC meeting ;)
> 

Sure! Will you attend?

Our Xenomai talk was accepted [1], and I'll hang around in Portland for
the whole ELC. We can do some hallway tracks or more if there is interest.

Jan

[1]
https://elciotna18.sched.com/event/DXnN/steering-xenomai-into-the-real-time-linux-future-jan-kiszka-siemens-ag

> On Fri, Jan 26, 2018 at 1:49 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2018-01-25 18:40, Philippe Gerum wrote:
>>>
>>> Here are some points I would like to discuss during this meeting. Please
>>> feel free to comment:
>>>
>>> 1. Release management
>>>
>>>       * Currently, the person who contributes most of the code is also the
>>> release manager, which is clearly not optimal. Both activities should be
>>> decoupled for efficiency (esp. hindsight) and practical reasons. At some
>>> point, I will stop acting as the release manager, so the project will
>>> need a different organization in this respect. Which one?
>>>
>>>       * As a corollary, the current release process is broken: no explicit
>>> release plan or schedule, limited testing, barely any user feedback
>>> about the development version in general. Practical steps to improve
>>> this should be discussed.
>>>
>>>       * My understanding is that v3.1 is almost there feature-wise, with a
>>> working arm64 port Dmitriy is polishing, a bunch of rtnet fixes actually
>>> enabling RTnet with SMAP/x86 (which still need some feedback btw), and
>>> support for recent kernels up to 4.14 (arm, arm64, powerpc). x86 is
>>> still lagging behind with kernel 4.9 though. I'm about to queue a couple
>>> of ABI changes more, with the implementation of sendmmsg() and
>>> recvmmsg() for RTDM sockets.
>>>
>>> This raises the following questions: 1) may we freeze the v3.1 ABI, 2)
>>> should we wait for supporting 4.14/x86 before releasing v3.1, 3) how
>>> much use/testing do we currently have of the -next branch, on which CPU
>>> architecture(s)?
>>>
>>> 2. Documentation
>>>
>>>       * The existing documentation has several weaknesses; from the traffic
>>> on the mailing list, the main one may be that it leaves newcomers with a
>>> steep learning curve, in some occasions, even when the information is
>>> published on the website and/or present in the inline documentation. How
>>> to improve the situation, how to better organize the existing doc so
>>> that people do find what they are looking for?
>>>
>>>       * Doxygen may not be the best option anymore for inline documentation;
>>> Chasing glitches with using the markup has been a real pain over the
>>> years, getting properly structured output has never been obvious. Could
>>> we do better with Doxygen in a reasonably simple fashion, or should
>>> reStructuredText and Sphinx be considered as a replacement, so that we
>>> can converge toward the kernel documentation system?
>>>
>>> 3. Pipeline maintenance
>>>
>>>       * We now have a dedicated I-pipe maintainer per CPU architecture, which
>>> is a great relief to me. Now I'd like we discuss the maintenance
>>> process, 1) how to organize the upstream/downstream flow of the generic
>>> pipeline bits I still maintain currently, between other maintainers and
>>> me? 2) how to best disseminate knowledge about the I-pipe implementation?
>>>
>>>       * mainline vs CIP kernel, LTS maintenance policy
>>>
>>> 4. Misc
>>>
>>>       * formalizing the decision about dropping the blackfin and powerpc64
>>> port, since we had zero feedback from users so far, so everyone must be
>>> fine with this.
>>>
>>> Thanks,
>>>
>>
>> Thanks for preparing this. Sounds good to me.
>>
>> Adding from Greg's points as well, we probably need to bring up bug
>> tracking together with the bigger topic workflow and related tooling.
>> This may easily make us run out of time, but a survey of opinions and
>> ideas in that round would be good to follow up on the list afterwards.
>>
>> Then testing. I would also not go into too much details, but it would be
>> good to understand what exist(ed) and what could be done easily to
>> improve it. Overlaps also with release management and with the good
>> proposal to define reference boards.
>>
>> How many days will our meeting have? ;)
>>
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> Corporate Competence Center Embedded Linux

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Greg Gallagher]

That would be great,  I booked my flights and hotel this morning.
Definitely attending the Xenomai talk and there was another talk on a
3D printer that is using Xenomai
(https://elciotna18.sched.com/event/DXmw/3d-printing-with-linux-and-xenomai-kendall-auel-3d-systems-corp)
that sounds like it will be interesting.  I'm up for anything Xenomai,
I'll be getting there late Sunday and leaving around 6pm Wednesday.

-Greg

On Fri, Jan 26, 2018 at 1:57 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2018-01-26 19:51, Greg Gallagher wrote:
>> We can add an ELC meeting ;)
>>
>
> Sure! Will you attend?
>
> Our Xenomai talk was accepted [1], and I'll hang around in Portland for
> the whole ELC. We can do some hallway tracks or more if there is interest.
>
> Jan
>
> [1]
> https://elciotna18.sched.com/event/DXnN/steering-xenomai-into-the-real-time-linux-future-jan-kiszka-siemens-ag
>
>> On Fri, Jan 26, 2018 at 1:49 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2018-01-25 18:40, Philippe Gerum wrote:
>>>>
>>>> Here are some points I would like to discuss during this meeting. Please
>>>> feel free to comment:
>>>>
>>>> 1. Release management
>>>>
>>>>       * Currently, the person who contributes most of the code is also the
>>>> release manager, which is clearly not optimal. Both activities should be
>>>> decoupled for efficiency (esp. hindsight) and practical reasons. At some
>>>> point, I will stop acting as the release manager, so the project will
>>>> need a different organization in this respect. Which one?
>>>>
>>>>       * As a corollary, the current release process is broken: no explicit
>>>> release plan or schedule, limited testing, barely any user feedback
>>>> about the development version in general. Practical steps to improve
>>>> this should be discussed.
>>>>
>>>>       * My understanding is that v3.1 is almost there feature-wise, with a
>>>> working arm64 port Dmitriy is polishing, a bunch of rtnet fixes actually
>>>> enabling RTnet with SMAP/x86 (which still need some feedback btw), and
>>>> support for recent kernels up to 4.14 (arm, arm64, powerpc). x86 is
>>>> still lagging behind with kernel 4.9 though. I'm about to queue a couple
>>>> of ABI changes more, with the implementation of sendmmsg() and
>>>> recvmmsg() for RTDM sockets.
>>>>
>>>> This raises the following questions: 1) may we freeze the v3.1 ABI, 2)
>>>> should we wait for supporting 4.14/x86 before releasing v3.1, 3) how
>>>> much use/testing do we currently have of the -next branch, on which CPU
>>>> architecture(s)?
>>>>
>>>> 2. Documentation
>>>>
>>>>       * The existing documentation has several weaknesses; from the traffic
>>>> on the mailing list, the main one may be that it leaves newcomers with a
>>>> steep learning curve, in some occasions, even when the information is
>>>> published on the website and/or present in the inline documentation. How
>>>> to improve the situation, how to better organize the existing doc so
>>>> that people do find what they are looking for?
>>>>
>>>>       * Doxygen may not be the best option anymore for inline documentation;
>>>> Chasing glitches with using the markup has been a real pain over the
>>>> years, getting properly structured output has never been obvious. Could
>>>> we do better with Doxygen in a reasonably simple fashion, or should
>>>> reStructuredText and Sphinx be considered as a replacement, so that we
>>>> can converge toward the kernel documentation system?
>>>>
>>>> 3. Pipeline maintenance
>>>>
>>>>       * We now have a dedicated I-pipe maintainer per CPU architecture, which
>>>> is a great relief to me. Now I'd like we discuss the maintenance
>>>> process, 1) how to organize the upstream/downstream flow of the generic
>>>> pipeline bits I still maintain currently, between other maintainers and
>>>> me? 2) how to best disseminate knowledge about the I-pipe implementation?
>>>>
>>>>       * mainline vs CIP kernel, LTS maintenance policy
>>>>
>>>> 4. Misc
>>>>
>>>>       * formalizing the decision about dropping the blackfin and powerpc64
>>>> port, since we had zero feedback from users so far, so everyone must be
>>>> fine with this.
>>>>
>>>> Thanks,
>>>>
>>>
>>> Thanks for preparing this. Sounds good to me.
>>>
>>> Adding from Greg's points as well, we probably need to bring up bug
>>> tracking together with the bigger topic workflow and related tooling.
>>> This may easily make us run out of time, but a survey of opinions and
>>> ideas in that round would be good to follow up on the list afterwards.
>>>
>>> Then testing. I would also not go into too much details, but it would be
>>> good to understand what exist(ed) and what could be done easily to
>>> improve it. Overlaps also with release management and with the good
>>> proposal to define reference boards.
>>>
>>> How many days will our meeting have? ;)
>>>
>>> Jan
>>>
>>> --
>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>> Corporate Competence Center Embedded Linux
>

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Jan Kiszka]

On 2018-01-26 20:02, Greg Gallagher wrote:
> That would be great,  I booked my flights and hotel this morning.
> Definitely attending the Xenomai talk and there was another talk on a
> 3D printer that is using Xenomai
> (https://elciotna18.sched.com/event/DXmw/3d-printing-with-linux-and-xenomai-kendall-auel-3d-systems-corp)

Cool! Didn't check the agenda yet.

> that sounds like it will be interesting.  I'm up for anything Xenomai,
> I'll be getting there late Sunday and leaving around 6pm Wednesday.

I'll have a couple of appointments, I suppose, but we could do a Xenomai
lunch. Maybe right away on Monday (Tuesdays would be before my talk, I
will likely need that time ;)).

Jan

> 
> -Greg
> 
> On Fri, Jan 26, 2018 at 1:57 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2018-01-26 19:51, Greg Gallagher wrote:
>>> We can add an ELC meeting ;)
>>>
>>
>> Sure! Will you attend?
>>
>> Our Xenomai talk was accepted [1], and I'll hang around in Portland for
>> the whole ELC. We can do some hallway tracks or more if there is interest.
>>
>> Jan
>>
>> [1]
>> https://elciotna18.sched.com/event/DXnN/steering-xenomai-into-the-real-time-linux-future-jan-kiszka-siemens-ag
>>
>>> On Fri, Jan 26, 2018 at 1:49 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> On 2018-01-25 18:40, Philippe Gerum wrote:
>>>>>
>>>>> Here are some points I would like to discuss during this meeting. Please
>>>>> feel free to comment:
>>>>>
>>>>> 1. Release management
>>>>>
>>>>>       * Currently, the person who contributes most of the code is also the
>>>>> release manager, which is clearly not optimal. Both activities should be
>>>>> decoupled for efficiency (esp. hindsight) and practical reasons. At some
>>>>> point, I will stop acting as the release manager, so the project will
>>>>> need a different organization in this respect. Which one?
>>>>>
>>>>>       * As a corollary, the current release process is broken: no explicit
>>>>> release plan or schedule, limited testing, barely any user feedback
>>>>> about the development version in general. Practical steps to improve
>>>>> this should be discussed.
>>>>>
>>>>>       * My understanding is that v3.1 is almost there feature-wise, with a
>>>>> working arm64 port Dmitriy is polishing, a bunch of rtnet fixes actually
>>>>> enabling RTnet with SMAP/x86 (which still need some feedback btw), and
>>>>> support for recent kernels up to 4.14 (arm, arm64, powerpc). x86 is
>>>>> still lagging behind with kernel 4.9 though. I'm about to queue a couple
>>>>> of ABI changes more, with the implementation of sendmmsg() and
>>>>> recvmmsg() for RTDM sockets.
>>>>>
>>>>> This raises the following questions: 1) may we freeze the v3.1 ABI, 2)
>>>>> should we wait for supporting 4.14/x86 before releasing v3.1, 3) how
>>>>> much use/testing do we currently have of the -next branch, on which CPU
>>>>> architecture(s)?
>>>>>
>>>>> 2. Documentation
>>>>>
>>>>>       * The existing documentation has several weaknesses; from the traffic
>>>>> on the mailing list, the main one may be that it leaves newcomers with a
>>>>> steep learning curve, in some occasions, even when the information is
>>>>> published on the website and/or present in the inline documentation. How
>>>>> to improve the situation, how to better organize the existing doc so
>>>>> that people do find what they are looking for?
>>>>>
>>>>>       * Doxygen may not be the best option anymore for inline documentation;
>>>>> Chasing glitches with using the markup has been a real pain over the
>>>>> years, getting properly structured output has never been obvious. Could
>>>>> we do better with Doxygen in a reasonably simple fashion, or should
>>>>> reStructuredText and Sphinx be considered as a replacement, so that we
>>>>> can converge toward the kernel documentation system?
>>>>>
>>>>> 3. Pipeline maintenance
>>>>>
>>>>>       * We now have a dedicated I-pipe maintainer per CPU architecture, which
>>>>> is a great relief to me. Now I'd like we discuss the maintenance
>>>>> process, 1) how to organize the upstream/downstream flow of the generic
>>>>> pipeline bits I still maintain currently, between other maintainers and
>>>>> me? 2) how to best disseminate knowledge about the I-pipe implementation?
>>>>>
>>>>>       * mainline vs CIP kernel, LTS maintenance policy
>>>>>
>>>>> 4. Misc
>>>>>
>>>>>       * formalizing the decision about dropping the blackfin and powerpc64
>>>>> port, since we had zero feedback from users so far, so everyone must be
>>>>> fine with this.
>>>>>
>>>>> Thanks,
>>>>>
>>>>
>>>> Thanks for preparing this. Sounds good to me.
>>>>
>>>> Adding from Greg's points as well, we probably need to bring up bug
>>>> tracking together with the bigger topic workflow and related tooling.
>>>> This may easily make us run out of time, but a survey of opinions and
>>>> ideas in that round would be good to follow up on the list afterwards.
>>>>
>>>> Then testing. I would also not go into too much details, but it would be
>>>> good to understand what exist(ed) and what could be done easily to
>>>> improve it. Overlaps also with release management and with the good
>>>> proposal to define reference boards.
>>>>
>>>> How many days will our meeting have? ;)
>>>>
>>>> Jan
>>>>
>>>> --
>>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>>> Corporate Competence Center Embedded Linux
>>

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Greg Gallagher]

Sounds good to me, I can send out a reminder to the list the week
before the conference.

On Fri, Jan 26, 2018 at 2:34 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2018-01-26 20:02, Greg Gallagher wrote:
>> That would be great,  I booked my flights and hotel this morning.
>> Definitely attending the Xenomai talk and there was another talk on a
>> 3D printer that is using Xenomai
>> (https://elciotna18.sched.com/event/DXmw/3d-printing-with-linux-and-xenomai-kendall-auel-3d-systems-corp)
>
> Cool! Didn't check the agenda yet.
>
>> that sounds like it will be interesting.  I'm up for anything Xenomai,
>> I'll be getting there late Sunday and leaving around 6pm Wednesday.
>
> I'll have a couple of appointments, I suppose, but we could do a Xenomai
> lunch. Maybe right away on Monday (Tuesdays would be before my talk, I
> will likely need that time ;)).
>
> Jan
>
>>
>> -Greg
>>
>> On Fri, Jan 26, 2018 at 1:57 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2018-01-26 19:51, Greg Gallagher wrote:
>>>> We can add an ELC meeting ;)
>>>>
>>>
>>> Sure! Will you attend?
>>>
>>> Our Xenomai talk was accepted [1], and I'll hang around in Portland for
>>> the whole ELC. We can do some hallway tracks or more if there is interest.
>>>
>>> Jan
>>>
>>> [1]
>>> https://elciotna18.sched.com/event/DXnN/steering-xenomai-into-the-real-time-linux-future-jan-kiszka-siemens-ag
>>>
>>>> On Fri, Jan 26, 2018 at 1:49 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>> On 2018-01-25 18:40, Philippe Gerum wrote:
>>>>>>
>>>>>> Here are some points I would like to discuss during this meeting. Please
>>>>>> feel free to comment:
>>>>>>
>>>>>> 1. Release management
>>>>>>
>>>>>>       * Currently, the person who contributes most of the code is also the
>>>>>> release manager, which is clearly not optimal. Both activities should be
>>>>>> decoupled for efficiency (esp. hindsight) and practical reasons. At some
>>>>>> point, I will stop acting as the release manager, so the project will
>>>>>> need a different organization in this respect. Which one?
>>>>>>
>>>>>>       * As a corollary, the current release process is broken: no explicit
>>>>>> release plan or schedule, limited testing, barely any user feedback
>>>>>> about the development version in general. Practical steps to improve
>>>>>> this should be discussed.
>>>>>>
>>>>>>       * My understanding is that v3.1 is almost there feature-wise, with a
>>>>>> working arm64 port Dmitriy is polishing, a bunch of rtnet fixes actually
>>>>>> enabling RTnet with SMAP/x86 (which still need some feedback btw), and
>>>>>> support for recent kernels up to 4.14 (arm, arm64, powerpc). x86 is
>>>>>> still lagging behind with kernel 4.9 though. I'm about to queue a couple
>>>>>> of ABI changes more, with the implementation of sendmmsg() and
>>>>>> recvmmsg() for RTDM sockets.
>>>>>>
>>>>>> This raises the following questions: 1) may we freeze the v3.1 ABI, 2)
>>>>>> should we wait for supporting 4.14/x86 before releasing v3.1, 3) how
>>>>>> much use/testing do we currently have of the -next branch, on which CPU
>>>>>> architecture(s)?
>>>>>>
>>>>>> 2. Documentation
>>>>>>
>>>>>>       * The existing documentation has several weaknesses; from the traffic
>>>>>> on the mailing list, the main one may be that it leaves newcomers with a
>>>>>> steep learning curve, in some occasions, even when the information is
>>>>>> published on the website and/or present in the inline documentation. How
>>>>>> to improve the situation, how to better organize the existing doc so
>>>>>> that people do find what they are looking for?
>>>>>>
>>>>>>       * Doxygen may not be the best option anymore for inline documentation;
>>>>>> Chasing glitches with using the markup has been a real pain over the
>>>>>> years, getting properly structured output has never been obvious. Could
>>>>>> we do better with Doxygen in a reasonably simple fashion, or should
>>>>>> reStructuredText and Sphinx be considered as a replacement, so that we
>>>>>> can converge toward the kernel documentation system?
>>>>>>
>>>>>> 3. Pipeline maintenance
>>>>>>
>>>>>>       * We now have a dedicated I-pipe maintainer per CPU architecture, which
>>>>>> is a great relief to me. Now I'd like we discuss the maintenance
>>>>>> process, 1) how to organize the upstream/downstream flow of the generic
>>>>>> pipeline bits I still maintain currently, between other maintainers and
>>>>>> me? 2) how to best disseminate knowledge about the I-pipe implementation?
>>>>>>
>>>>>>       * mainline vs CIP kernel, LTS maintenance policy
>>>>>>
>>>>>> 4. Misc
>>>>>>
>>>>>>       * formalizing the decision about dropping the blackfin and powerpc64
>>>>>> port, since we had zero feedback from users so far, so everyone must be
>>>>>> fine with this.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>
>>>>> Thanks for preparing this. Sounds good to me.
>>>>>
>>>>> Adding from Greg's points as well, we probably need to bring up bug
>>>>> tracking together with the bigger topic workflow and related tooling.
>>>>> This may easily make us run out of time, but a survey of opinions and
>>>>> ideas in that round would be good to follow up on the list afterwards.
>>>>>
>>>>> Then testing. I would also not go into too much details, but it would be
>>>>> good to understand what exist(ed) and what could be done easily to
>>>>> improve it. Overlaps also with release management and with the good
>>>>> proposal to define reference boards.
>>>>>
>>>>> How many days will our meeting have? ;)
>>>>>
>>>>> Jan
>>>>>
>>>>> --
>>>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>>>> Corporate Competence Center Embedded Linux
>>>
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Auel, Kendall]

I've been lurking on this list for a while, and looking forward to seeing some of you face-to-face. I'm a Portland native, so feel free to use me as a resource when planning your visit.

> -----Original Message-----
> From: Xenomai [mailto:xenomai-bounces@xenomai.org] On Behalf Of Greg
> Gallagher
> Sent: Friday, January 26, 2018 11:02 AM
> To: Jan Kiszka <jan.kiszka@siemens.com>
> Cc: Steven Seeger <steven.seeger@nasa.gov>; Xenomai@xenomai.org
> Subject: Re: [Xenomai] [RFC] FOSDEM meeting agenda
> 
> That would be great,  I booked my flights and hotel this morning.
> Definitely attending the Xenomai talk and there was another talk on a 3D
> printer that is using Xenomai
> (https://elciotna18.sched.com/event/DXmw/3d-printing-with-linux-and-xenomai-kendall-auel-3d-systems-corp)
> that sounds like it will be interesting.  I'm up for anything Xenomai, I'll be
> getting there late Sunday and leaving around 6pm Wednesday.
> 
> -Greg
> 
> On Fri, Jan 26, 2018 at 1:57 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > On 2018-01-26 19:51, Greg Gallagher wrote:
> >> We can add an ELC meeting ;)
> >>
> >
> > Sure! Will you attend?
> >
> > Our Xenomai talk was accepted [1], and I'll hang around in Portland
> > for the whole ELC. We can do some hallway tracks or more if there is
> interest.
> >
> > Jan
> >
> > [1]
> > https://elciotna18.sched.com/event/DXnN/steering-xenomai-into-the-
> real
> > -time-linux-future-jan-kiszka-siemens-ag
> >
> >> On Fri, Jan 26, 2018 at 1:49 PM, Jan Kiszka <jan.kiszka@siemens.com>
> wrote:
> >>> On 2018-01-25 18:40, Philippe Gerum wrote:
> >>>>
> >>>> Here are some points I would like to discuss during this meeting.
> >>>> Please feel free to comment:
> >>>>
> >>>> 1. Release management
> >>>>
> >>>>       * Currently, the person who contributes most of the code is
> >>>> also the release manager, which is clearly not optimal. Both
> >>>> activities should be decoupled for efficiency (esp. hindsight) and
> >>>> practical reasons. At some point, I will stop acting as the release
> >>>> manager, so the project will need a different organization in this
> respect. Which one?
> >>>>
> >>>>       * As a corollary, the current release process is broken: no
> >>>> explicit release plan or schedule, limited testing, barely any user
> >>>> feedback about the development version in general. Practical steps
> >>>> to improve this should be discussed.
> >>>>
> >>>>       * My understanding is that v3.1 is almost there feature-wise,
> >>>> with a working arm64 port Dmitriy is polishing, a bunch of rtnet
> >>>> fixes actually enabling RTnet with SMAP/x86 (which still need some
> >>>> feedback btw), and support for recent kernels up to 4.14 (arm,
> >>>> arm64, powerpc). x86 is still lagging behind with kernel 4.9
> >>>> though. I'm about to queue a couple of ABI changes more, with the
> >>>> implementation of sendmmsg() and
> >>>> recvmmsg() for RTDM sockets.
> >>>>
> >>>> This raises the following questions: 1) may we freeze the v3.1 ABI,
> >>>> 2) should we wait for supporting 4.14/x86 before releasing v3.1, 3)
> >>>> how much use/testing do we currently have of the -next branch, on
> >>>> which CPU architecture(s)?
> >>>>
> >>>> 2. Documentation
> >>>>
> >>>>       * The existing documentation has several weaknesses; from the
> >>>> traffic on the mailing list, the main one may be that it leaves
> >>>> newcomers with a steep learning curve, in some occasions, even when
> >>>> the information is published on the website and/or present in the
> >>>> inline documentation. How to improve the situation, how to better
> >>>> organize the existing doc so that people do find what they are looking
> for?
> >>>>
> >>>>       * Doxygen may not be the best option anymore for inline
> >>>> documentation; Chasing glitches with using the markup has been a
> >>>> real pain over the years, getting properly structured output has
> >>>> never been obvious. Could we do better with Doxygen in a reasonably
> >>>> simple fashion, or should reStructuredText and Sphinx be considered
> >>>> as a replacement, so that we can converge toward the kernel
> documentation system?
> >>>>
> >>>> 3. Pipeline maintenance
> >>>>
> >>>>       * We now have a dedicated I-pipe maintainer per CPU
> >>>> architecture, which is a great relief to me. Now I'd like we
> >>>> discuss the maintenance process, 1) how to organize the
> >>>> upstream/downstream flow of the generic pipeline bits I still
> >>>> maintain currently, between other maintainers and me? 2) how to best
> disseminate knowledge about the I-pipe implementation?
> >>>>
> >>>>       * mainline vs CIP kernel, LTS maintenance policy
> >>>>
> >>>> 4. Misc
> >>>>
> >>>>       * formalizing the decision about dropping the blackfin and
> >>>> powerpc64 port, since we had zero feedback from users so far, so
> >>>> everyone must be fine with this.
> >>>>
> >>>> Thanks,
> >>>>
> >>>
> >>> Thanks for preparing this. Sounds good to me.
> >>>
> >>> Adding from Greg's points as well, we probably need to bring up bug
> >>> tracking together with the bigger topic workflow and related tooling.
> >>> This may easily make us run out of time, but a survey of opinions
> >>> and ideas in that round would be good to follow up on the list
> afterwards.
> >>>
> >>> Then testing. I would also not go into too much details, but it
> >>> would be good to understand what exist(ed) and what could be done
> >>> easily to improve it. Overlaps also with release management and with
> >>> the good proposal to define reference boards.
> >>>
> >>> How many days will our meeting have? ;)
> >>>
> >>> Jan
> >>>
> >>> --
> >>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
> >>> Competence Center Embedded Linux
> >
> 
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Philippe Gerum]

On 01/26/2018 07:49 PM, Jan Kiszka wrote:
> 
> Then testing. I would also not go into too much details, but it would be
> good to understand what exist(ed) and what could be done easily to
> improve it.

That I can answer quickly: over the years, we went from manual testing I
was carrying out over a couple of boards for each of the supported
architectures, to a home-made CI system Gilles had developed, which was
hosted on his server.

That system did automated nightly build tests for every architectures,
and latency measurements under stress periodically, for a few ARM SoCs
of the common ARM architectures back then (armv4, armv5, then later
armv7), generating latency reports. x86(32/64) testing was shared
between Gilles (early atom-based board) and I (i5 and atom). Other CPU
architectures were on my plate (e.g. ppc(32|64), blackfin - ia64, nios2
and sh4 when Xenomai was still supporting them).

Since we lost Gilles, no CI system has been available. We once had plans
to rehost our CI from the home-made infrastructure to a publicly
available automation server, but could not pursue mainly due to a lack
of time for putting the pieces together.

Today, I'm generally able to do proper testing on ARM* SoCs (armv7,
armv8 exclusively though) and x86, because this matches the target
architectures of some of my contract work.

-- 
Philippe.

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Pierre FICHEUX]

Hi all,

Is there anywhere  a kind of report for the last Xenomai meeting?

-- 
Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux@smile.fr
                              http://www.smile.fr
                              https://smile.eu/fr/offres/embarque-iot
I would love to change the world, but they won't give me the source 
code

Le 2018-01-27 12:31, Philippe Gerum a écrit :
> On 01/26/2018 07:49 PM, Jan Kiszka wrote:
>> 
>> Then testing. I would also not go into too much details, but it would 
>> be
>> good to understand what exist(ed) and what could be done easily to
>> improve it.
> 
> That I can answer quickly: over the years, we went from manual testing 
> I
> was carrying out over a couple of boards for each of the supported
> architectures, to a home-made CI system Gilles had developed, which 
> was
> hosted on his server.
> 
> That system did automated nightly build tests for every architectures,
> and latency measurements under stress periodically, for a few ARM SoCs
> of the common ARM architectures back then (armv4, armv5, then later
> armv7), generating latency reports. x86(32/64) testing was shared
> between Gilles (early atom-based board) and I (i5 and atom). Other CPU
> architectures were on my plate (e.g. ppc(32|64), blackfin - ia64, 
> nios2
> and sh4 when Xenomai was still supporting them).
> 
> Since we lost Gilles, no CI system has been available. We once had 
> plans
> to rehost our CI from the home-made infrastructure to a publicly
> available automation server, but could not pursue mainly due to a lack
> of time for putting the pieces together.
> 
> Today, I'm generally able to do proper testing on ARM* SoCs (armv7,
> armv8 exclusively though) and x86, because this matches the target
> architectures of some of my contract work.