[Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

As the GIT commit history shows, there has been no sustained effort in
maintaining several of the Xenomai I/O frameworks for several months
(e.g. RTnet, analogy), even years in some cases, despite obvious bugs
are still haunting the code base according to the mailing list. The
situation has reached a point where I see no alternative to dropping
them if the situation does not improve, because there is absolutely no
point in this project shipping bit rot software that won't ever be fixed.

Unfortunately, this is only the tip of the iceberg. Let's face it, since
Gilles passed away last year, I have not been scaling to the Xenomai
maintenance, development and documentation tasks, with the requirement
of running my business in parallel.

The solution to this serious problem is fitting the project to the
available resources by narrowing its goal, or conversely, by growing the
pool of contributors.

In addition, we can rework the most tricky part of the implementation to
make it simpler to maintain, better documented, drastically lowering the
barrier on entry for new contributors, which is what I've been working
on for a year with the 4th generation of the interrupt pipeline.
Progress on this front has been significant already, but once again
limited by the time I have been able to devote to this development so far.

For the past 16 years, this project has lived on various types of
contributions from only a few committed people and companies. At this
chance, let's mention that people who have been deploying Xenomai in
industrial applications owe a lot to Wolfgang Denk from Denx
Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported
the project in crucial ways directly or indirectly over the years, and
still do.

Xenomai as a dual kernel technology showcase has been quietly delivering
on the promise of real-time Linux for more than a decade now, with
marketing tools limited to showing decent code quality, good and
reliable performance figures. As a result, to my current knowledge,
Xenomai is present in a broad range of applications and systems:
magnetic resonance scanners, 2D/3D printers, navigation & positioning,
communication equipment, autonomous vehicles, control & automation
systems in various plants.

On the sad side of the story, this project has virtually become a
one-man show the day Gilles - my long-time friend and hacking soul mate
- left us. That show is too big for me to run it alone, which entails
maintaining:

- the interrupt pipeline for 7 CPU architectures
- the Cobalt co-kernel
- 4 APIs, plus the "copperplate" mediating layer
- several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI, GPIO
- the documentation (which is currently unfriendly to newcomers, and
stalled two years ago or so)
- the website
- the testing and release processes

So, let's talk about the elephant in the room: the current situation of
the Xenomai project is not viable in the long run. I can only encourage
people who feel concerned about it to discuss openly the practical steps
to best address this challenge.

Thanks,

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Greg Gallagher]

Hi,
   I've been using Xenomai for a couple of years now and having been
preparing my first patch.
I'd love to help any way that is needed.  Documentation may be a good place
for me to start.  I'd also
be more than happy to help maintain some of the I/O frameworks.  I would
probably need a mentor
for guidance at the beginning.

Thanks

On Tue, Nov 21, 2017 at 12:11 PM, Philippe Gerum <rpm@xenomai.org> wrote:

>
> As the GIT commit history shows, there has been no sustained effort in
> maintaining several of the Xenomai I/O frameworks for several months
> (e.g. RTnet, analogy), even years in some cases, despite obvious bugs
> are still haunting the code base according to the mailing list. The
> situation has reached a point where I see no alternative to dropping
> them if the situation does not improve, because there is absolutely no
> point in this project shipping bit rot software that won't ever be fixed.
>
> Unfortunately, this is only the tip of the iceberg. Let's face it, since
> Gilles passed away last year, I have not been scaling to the Xenomai
> maintenance, development and documentation tasks, with the requirement
> of running my business in parallel.
>
> The solution to this serious problem is fitting the project to the
> available resources by narrowing its goal, or conversely, by growing the
> pool of contributors.
>
> In addition, we can rework the most tricky part of the implementation to
> make it simpler to maintain, better documented, drastically lowering the
> barrier on entry for new contributors, which is what I've been working
> on for a year with the 4th generation of the interrupt pipeline.
> Progress on this front has been significant already, but once again
> limited by the time I have been able to devote to this development so far.
>
> For the past 16 years, this project has lived on various types of
> contributions from only a few committed people and companies. At this
> chance, let's mention that people who have been deploying Xenomai in
> industrial applications owe a lot to Wolfgang Denk from Denx
> Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported
> the project in crucial ways directly or indirectly over the years, and
> still do.
>
> Xenomai as a dual kernel technology showcase has been quietly delivering
> on the promise of real-time Linux for more than a decade now, with
> marketing tools limited to showing decent code quality, good and
> reliable performance figures. As a result, to my current knowledge,
> Xenomai is present in a broad range of applications and systems:
> magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> communication equipment, autonomous vehicles, control & automation
> systems in various plants.
>
> On the sad side of the story, this project has virtually become a
> one-man show the day Gilles - my long-time friend and hacking soul mate
> - left us. That show is too big for me to run it alone, which entails
> maintaining:
>
> - the interrupt pipeline for 7 CPU architectures
> - the Cobalt co-kernel
> - 4 APIs, plus the "copperplate" mediating layer
> - several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI,
> GPIO
> - the documentation (which is currently unfriendly to newcomers, and
> stalled two years ago or so)
> - the website
> - the testing and release processes
>
> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.
>
> Thanks,
>
> --
> Philippe.
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Auel, Kendall]

Hi Philippe,

Is there an online bug tracking and feature request database? This would be a useful way to distribute work and to sync up contributors. I think the kernel uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.

I'd like to contribute in some way. I've been having a lot of fun as a Xenomai user.

Regards,
Kendall


-----Original Message-----
From: Xenomai [mailto:xenomai-bounces@xenomai.org] On Behalf Of Philippe Gerum
Sent: Tuesday, November 21, 2017 9:12 AM
To: Xenomai@xenomai.org
Subject: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room


As the GIT commit history shows, there has been no sustained effort in maintaining several of the Xenomai I/O frameworks for several months (e.g. RTnet, analogy), even years in some cases, despite obvious bugs are still haunting the code base according to the mailing list. The situation has reached a point where I see no alternative to dropping them if the situation does not improve, because there is absolutely no point in this project shipping bit rot software that won't ever be fixed.

Unfortunately, this is only the tip of the iceberg. Let's face it, since Gilles passed away last year, I have not been scaling to the Xenomai maintenance, development and documentation tasks, with the requirement of running my business in parallel.

The solution to this serious problem is fitting the project to the available resources by narrowing its goal, or conversely, by growing the pool of contributors.

In addition, we can rework the most tricky part of the implementation to make it simpler to maintain, better documented, drastically lowering the barrier on entry for new contributors, which is what I've been working on for a year with the 4th generation of the interrupt pipeline.
Progress on this front has been significant already, but once again limited by the time I have been able to devote to this development so far.

For the past 16 years, this project has lived on various types of contributions from only a few committed people and companies. At this chance, let's mention that people who have been deploying Xenomai in industrial applications owe a lot to Wolfgang Denk from Denx Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported the project in crucial ways directly or indirectly over the years, and still do.

Xenomai as a dual kernel technology showcase has been quietly delivering on the promise of real-time Linux for more than a decade now, with marketing tools limited to showing decent code quality, good and reliable performance figures. As a result, to my current knowledge, Xenomai is present in a broad range of applications and systems:
magnetic resonance scanners, 2D/3D printers, navigation & positioning, communication equipment, autonomous vehicles, control & automation systems in various plants.

On the sad side of the story, this project has virtually become a one-man show the day Gilles - my long-time friend and hacking soul mate
- left us. That show is too big for me to run it alone, which entails
maintaining:

- the interrupt pipeline for 7 CPU architectures
- the Cobalt co-kernel
- 4 APIs, plus the "copperplate" mediating layer
- several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI, GPIO
- the documentation (which is currently unfriendly to newcomers, and stalled two years ago or so)
- the website
- the testing and release processes

So, let's talk about the elephant in the room: the current situation of the Xenomai project is not viable in the long run. I can only encourage people who feel concerned about it to discuss openly the practical steps to best address this challenge.

Thanks,

--
Philippe.

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Dmitriy Cherkasov]

On 11/21/2017 09:11 AM, Philippe Gerum wrote:

> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.

Hi Philippe,

I would be happy to help any way that I can, especially with any of the new 
pipeline work.

Having said that, I think this is a good discussion to have. If there are 
commercial or institutional users of any of the somewhat neglected subsystems, 
this would be a good time to remind them to invest some resources into 
maintaining these things in the upstream project.

I think in general, hobbyist contributors will mostly work on what they find 
interesting to themselves, and if there is no hobbyist or commercial support for 
certain features then perhaps it does make sense to drop them.

-Dmitriy

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Leopold Palomo-Avellaneda]

Hi,

yes, it's true. We have an Elmer and his cousin Wilbur is rear the door.

Let me remark some points of your great email:

- about the I/O frameworks

On 21/11/17 18:11, Philippe Gerum wrote:
> The
> situation has reached a point where I see no alternative to dropping
> them if the situation does not improve, ...

- about your rule in the project:

> I have not been scaling to the Xenomai
> maintenance, development and documentation tasks, with the requirement
> of running my business in parallel.

- about how to solve it:

> The solution to this serious problem is fitting the project to the
> available resources by narrowing its goal, or conversely, by growing the
> pool of contributors.

- about the presence of Xenomai in the world:

> to my current knowledge,
> Xenomai is present in a broad range of applications and systems:
> magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> communication equipment, autonomous vehicles, control & automation
> systems in various plants.

- about where we came from:

> On the sad side of the story, this project has virtually become a
> one-man show the day Gilles - my long-time friend and hacking soul mate
> - left us. That show is too big for me to run it alone ...


And finally, if you let me talk about our Elmer.

The I/O frameworks are IMHO are crucial. It has a very limited scenario to
develop a RT system if it has no interaction with the external devices, or
whatever. I have the hope ("A new hope" ;-)) that Siemens and Denx guys,
continuing contributing to the project. Also, I have seen that new people have
interest.

But I would like to ask you directly Philippe some practical steps that could
address to this challenge:

- Would you be willing to move Xenomai to some platform like github, or similar?
It will have some advantages like issues management, maintenance, (more
visibility?), etc.

- Would you be willing to delegate tasks of the project to other people, that
maybe will not make it as good as you will do, like documentation, web site, or
parts of code, but made then with an acceptable quality? And please, don't take
bad, it's a difficult thing. I have to confess that for me, it's very difficult.

- Would you be willing to guide new contributors and give them responsibilities
of important parts of the code?

- Would you be willing to have the role as coordinator and leader of the project
changing from one man show to some more open project? will be it possible? I
don't know if because license issues or whatever would let it...

- Would you be willing to change the build system from autotools to another
modern tool? (Ex CMake?) IMHO few people understand autotools and it's a barrier
for the new contributors, at least in another opensource projects. However, I
have to admit that the entry level in Xenomai is high, so, autotools should not
be a problem.

And yes, the lost of Gilles was a great blow, on a the personal level and for
his contributions on the project.

From my part, I can contribute if there's interest, in Debian (Ubuntu) packages.
Also, in testing and trying to help in the RTnet part, as user that I'm. So, I
could try to provide some preconfigured scenarios to the people that would like
to entry in Xenomai.

I have to admit that I'm a bit scared because we depend of Xenomai in some
projects in my University. But, probably we could try to move to RT_PREMPT. But,
because its history and my "affection" for the project I would prefer stay with
it and try to help.

Cheers,

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20171122/af6d7b02/attachment.sig>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Greg Gallagher]

    I really like the idea of having some TODO files, this would given new
comers to the project a place to start.
Improving the documentation and adding a quick start guide might help get
more people interested in using
Xenomai.  With more users hopefully that would lead to more contributors
and not just more feature requests.

    To increase the presence of Xenomai would it make sense to have some
people focus on drivers and
maintenance for some popular community boards?  I personally focus on the
Xilinx Zynq platform,
but it might be useful to have people build and test images for  raspberry
pi boards, beaglebones and other
popular maker boards for every stable release of Xenomai.  I've posted my
steps on how to build Xenomai
for Zynq and will start to build and maintain pre-built binaries for Zynq
and run tests for the boards I have access to.
I find a lot of people that give me feedback on the Xenomai on Zynq seem to
just want to get started quickly
and go.  This really only addresses increasing Xenomai presence and would
increase the total work which
might not be what's desired right now.


On Wed, Nov 22, 2017 at 7:33 AM, Leopold Palomo-Avellaneda <leo@alaxarxa.net
> wrote:

> Hi,
>
> yes, it's true. We have an Elmer and his cousin Wilbur is rear the door.
>
> Let me remark some points of your great email:
>
> - about the I/O frameworks
>
> On 21/11/17 18:11, Philippe Gerum wrote:
> > The
> > situation has reached a point where I see no alternative to dropping
> > them if the situation does not improve, ...
>
> - about your rule in the project:
>
> > I have not been scaling to the Xenomai
> > maintenance, development and documentation tasks, with the requirement
> > of running my business in parallel.
>
> - about how to solve it:
>
> > The solution to this serious problem is fitting the project to the
> > available resources by narrowing its goal, or conversely, by growing the
> > pool of contributors.
>
> - about the presence of Xenomai in the world:
>
> > to my current knowledge,
> > Xenomai is present in a broad range of applications and systems:
> > magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> > communication equipment, autonomous vehicles, control & automation
> > systems in various plants.
>
> - about where we came from:
>
> > On the sad side of the story, this project has virtually become a
> > one-man show the day Gilles - my long-time friend and hacking soul mate
> > - left us. That show is too big for me to run it alone ...
>
>
> And finally, if you let me talk about our Elmer.
>
> The I/O frameworks are IMHO are crucial. It has a very limited scenario to
> develop a RT system if it has no interaction with the external devices, or
> whatever. I have the hope ("A new hope" ;-)) that Siemens and Denx guys,
> continuing contributing to the project. Also, I have seen that new people
> have
> interest.
>
> But I would like to ask you directly Philippe some practical steps that
> could
> address to this challenge:
>
> - Would you be willing to move Xenomai to some platform like github, or
> similar?
> It will have some advantages like issues management, maintenance, (more
> visibility?), etc.
>
> - Would you be willing to delegate tasks of the project to other people,
> that
> maybe will not make it as good as you will do, like documentation, web
> site, or
> parts of code, but made then with an acceptable quality? And please, don't
> take
> bad, it's a difficult thing. I have to confess that for me, it's very
> difficult.
>
> - Would you be willing to guide new contributors and give them
> responsibilities
> of important parts of the code?
>
> - Would you be willing to have the role as coordinator and leader of the
> project
> changing from one man show to some more open project? will be it possible?
> I
> don't know if because license issues or whatever would let it...
>
> - Would you be willing to change the build system from autotools to another
> modern tool? (Ex CMake?) IMHO few people understand autotools and it's a
> barrier
> for the new contributors, at least in another opensource projects.
> However, I
> have to admit that the entry level in Xenomai is high, so, autotools
> should not
> be a problem.
>
> And yes, the lost of Gilles was a great blow, on a the personal level and
> for
> his contributions on the project.
>
> From my part, I can contribute if there's interest, in Debian (Ubuntu)
> packages.
> Also, in testing and trying to help in the RTnet part, as user that I'm.
> So, I
> could try to provide some preconfigured scenarios to the people that would
> like
> to entry in Xenomai.
>
> I have to admit that I'm a bit scared because we depend of Xenomai in some
> projects in my University. But, probably we could try to move to
> RT_PREMPT. But,
> because its history and my "affection" for the project I would prefer stay
> with
> it and try to help.
>
> Cheers,
>
> Leopold
>
> --
> --
> Linux User 152692     GPG: 05F4A7A949A2D9AA
> Catalonia
> -------------------------------------
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: OpenPGP digital signature
> URL: <http://xenomai.org/pipermail/xenomai/attachments/20171122/
> af6d7b02/attachment.sig>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/21/2017 06:26 PM, Greg Gallagher wrote:
> Hi,
>    I've been using Xenomai for a couple of years now and having been
> preparing my first patch.
> I'd love to help any way that is needed.  Documentation may be a good place
> for me to start.

There is no shortage of work on the documentation side. This would
definitely help a lot, thanks. To this end, it would be helpful if
people shared their experience about the most obvious issues they faced
with the existing documentation when discovering Xenomai.

>  I'd also
> be more than happy to help maintain some of the I/O frameworks.  I would
> probably need a mentor
> for guidance at the beginning.
> 

I'm willing to help anyone willing to contribute.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

Hi Kendall,

On 11/21/2017 08:27 PM, Auel, Kendall wrote:
> Hi Philippe,
> 
> Is there an online bug tracking and feature request database? This would be a useful way to distribute work and to sync up contributors. I think the kernel uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.
> 
> I'd like to contribute in some way. I've been having a lot of fun as a Xenomai user.
> 
We don't have that unfortunately. As suggested by several posters,
moving to a git-based, integrated development framework such as gitlab
or github would bring in that feature, and others we need too (CI).

I have no issue moving the project from the current git server at
xenomai.org to any of these environments.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/21/2017 08:54 PM, Dmitriy Cherkasov wrote:
> On 11/21/2017 09:11 AM, Philippe Gerum wrote:
> 
>> So, let's talk about the elephant in the room: the current situation of
>> the Xenomai project is not viable in the long run. I can only encourage
>> people who feel concerned about it to discuss openly the practical steps
>> to best address this challenge.
> 
> Hi Philippe,
> 
> I would be happy to help any way that I can, especially with any of the
> new pipeline work.
> 
We may want to discuss this in a separate thread if interested, however
some context may fit here:

linux-steely (master branch) as visible on the git server contains the
current state of this work, tracking the mainline tip as closely as
possible (up to commit #83bfd83650cc, anything on top is a new co-kernel
derived from Cobalt I'm toying with for experimenting with the pipeline
and new ideas for a better integration in Linux).

The development took place on imx6qp and imx7d so far; I want to port
this to aarch64 and started to do so. imx can run the basic tests, the
aarch64 port does not boot yet. The whole thing is still very much in a
state of flux, as better ways to make dual kernel support a basic Linux
feature - instead of a set of unrelated sideways - appear.

A reasonable plan would be to interface Xenomai's Cobalt core with the
new pipeline at some point, while keeping the I-pipe option available,
gradually phasing out the current I-pipe generation as the new one matures.

> Having said that, I think this is a good discussion to have. If there
> are commercial or institutional users of any of the somewhat neglected
> subsystems, this would be a good time to remind them to invest some
> resources into maintaining these things in the upstream project.
> 

Feedback and proposals for even simple changes which may help users in
the future are valuable contributions too, which come at virtually no
cost. Once a problem is stated, resources to fix it may be looked for.

> I think in general, hobbyist contributors will mostly work on what they
> find interesting to themselves, and if there is no hobbyist or
> commercial support for certain features then perhaps it does make sense
> to drop them.
> 
Ack. At any rate, shipping bit rot software people would unfortunately
rely upon never helped anyone.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Jan Kiszka]

On 2017-11-21 18:11, Philippe Gerum wrote:
> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.

Thanks for bringing this frankly on the table! For those who follow the
project, it's likely no news. So we were working on this issue also
internally, with users of Xenomai inside Siemens. And we have the
backing to enhance our involvement in upstream work. Right now we are
working on making this concrete.

There are many areas where contributions can be beneficial for the
project and its community, and many do not require deepest understanding
of the core, like around CI, test automation, distro packaging,
documentation, or user support. But some essential elements in my eyes are

 - building up a core team of kernel maintainers for Cobalt

 - offloading work from the shoulders of our extremely valuable
   maintainer

The second part will be achieved to a certain degree by the first one as
Philippe can probably confirm. So I would like to focus this and try to
make some first step:

We are currently planning a so far internal workshop with Philippe in
order to discuss how to bring more of our people but also others on
board regarding kernel maintenance topics. Topics to discussed are likely

 - current design and how to introduce people to it (tough, yeah...)
 - possible workflows and integration paths
 - update strategy and frequency
 - testing needs and strategies
 - supportable architectures
 - state and details of the new pipeline design
 - planning of and migration path to the new design

If there is interest in joining such a discussion, physically (will
likely take place in our office in Munich, Germany) or virtually
(provided time zones work out), please let us know. Time frame is more
likely early next year than mid of this December. And this shall be only
the kickoff for further discussions in the community!

Jan

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

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Jan Kiszka]

On 2017-11-22 16:32, Philippe Gerum wrote:
> 
> Hi Kendall,
> 
> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>> Hi Philippe,
>>
>> Is there an online bug tracking and feature request database? This would be a useful way to distribute work and to sync up contributors. I think the kernel uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.
>>
>> I'd like to contribute in some way. I've been having a lot of fun as a Xenomai user.
>>
> We don't have that unfortunately. As suggested by several posters,
> moving to a git-based, integrated development framework such as gitlab
> or github would bring in that feature, and others we need too (CI).
> 
> I have no issue moving the project from the current git server at
> xenomai.org to any of these environments.
> 

If it helps the community to grow, I would not refuse such a move. But I
would like to raise some concerns about platforms like github or gitlab
that we must be aware of:

- lacking integration with email-based workflows (while kernel
  development tends to be based on that...)

- risk of decoupling communities when parts of the discussions happen on
  tickets or PRs and parts in mailing list threads

Therefore, most projects I manage on github and in our internal gitlab
have clear policies like "no emails, only tickets and PRs" or "no PRs,
only patches on the mailing list". Even just using the issue tracker to
keep some to-do list requires discipline to direct discussions
consequently to a mailing list if that exists as well (and that usually
does not work very well).

IOW: we need to be clear in what we want a platform for - and what not.

Jan

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

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/22/2017 01:33 PM, Leopold Palomo-Avellaneda wrote:

[snip]

> 
> And finally, if you let me talk about our Elmer.
> 
> The I/O frameworks are IMHO are crucial. It has a very limited scenario to
> develop a RT system if it has no interaction with the external devices, or
> whatever. I have the hope ("A new hope" ;-)) that Siemens and Denx guys,
> continuing contributing to the project. Also, I have seen that new people have
> interest.
>

For the record, I'm definitely not suggesting to drop all I/O device
support from Xenomai, that would obviously make no sense. However, the
broken code must be fixed otherwise it serves no purpose but annoying
both users and maintainers.

> But I would like to ask you directly Philippe some practical steps that could
> address to this challenge:
> 
> - Would you be willing to move Xenomai to some platform like github, or similar?
> It will have some advantages like issues management, maintenance, (more
> visibility?), etc.
> 

Yes.

> - Would you be willing to delegate tasks of the project to other people,

Yes.

 that
> maybe will not make it as good as you will do, like documentation, web site, or
> parts of code, but made then with an acceptable quality?

Yes. This said, acceptable quality is a matter of taste and perception,
and the people involved in the merging process may have different views
on this. Fortunately for us, crap always solidly looks crap, which eases
the decision process when deciding what to do with it.

 And please, don't take
> bad, it's a difficult thing. I have to confess that for me, it's very difficult.
> > - Would you be willing to guide new contributors and give them
responsibilities
> of important parts of the code?
> 

Yes. However, we cannot expect anyone to decide for us what we could be
interested in contributing. What needs to be done can be put on the
table for discussion, people may add new ideas, but at the end of the
day, one is responsible for committing to a task.

> - Would you be willing to have the role as coordinator and leader of the project
> changing from one man show to some more open project? will be it possible? I

This is already the situation today, the real issue is that I'm
contributing most of the code, and have to carry out all of the other
tasks in the project, which ends up with nothing being done with the
required level of predictability and quality.

Even more importantly, most of the knowledge about how things work
internally all across the core system over all CPU architectures is
dangerously concentrated into a single person's brain. With a bus factor
of 1, well, Houston, we have a problem.

Information must flow, as a matter of fact, it does not, at the very
least not enough. This is clearly not a matter of unwillingness from my
end, but I tend to get lazy writing documentation about the internal
stuff when I'm not explicitly challenged to provide information by
people involved in the project.

> don't know if because license issues or whatever would let it...
>

The licensing scheme is very simple (fully abide by the kernel GPL
license for anything living in kernel space, use LGPL for libs in
userland) and did not change for the past 15 years, I'm not aware of any
issue so far.

> - Would you be willing to change the build system from autotools to another
> modern tool? (Ex CMake?) IMHO few people understand autotools and it's a barrier
> for the new contributors, at least in another opensource projects. However, I
> have to admit that the entry level in Xenomai is high, so, autotools should not
> be a problem.

I'm not excluding any change at this stage, which includes considering
other options in replacement of the autotools. This said, I don't think
the tool supporting build recipes can prevent anyone to contribute
software. In kernel space, Kbuild has to be followed and autotools are
not involved at all. In user-space, a recipe to build an exec or a
library is about 10 lines of a Makefile template, with many examples
around. And the mailing list has always been there for people to ask
specific questions about this.

> 
> And yes, the lost of Gilles was a great blow, on a the personal level and for
> his contributions on the project.
> 
>>From my part, I can contribute if there's interest, in Debian (Ubuntu) packages.
> Also, in testing and trying to help in the RTnet part, as user that I'm. So, I
> could try to provide some preconfigured scenarios to the people that would like
> to entry in Xenomai.
> 
> I have to admit that I'm a bit scared because we depend of Xenomai in some
> projects in my University. But, probably we could try to move to RT_PREMPT. But,
> because its history and my "affection" for the project I would prefer stay with
> it and try to help.
> 

Talking about the elephant in the room does not make it scarier, it has
always been there.

-- 
Philippe.

[Xenomai] [RFC] Service hosting for Xenomai

[Philippe Gerum]

On 11/22/2017 09:27 PM, Jan Kiszka wrote:
> On 2017-11-22 16:32, Philippe Gerum wrote:
>>
>> Hi Kendall,
>>
>> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>>> Hi Philippe,
>>>
>>> Is there an online bug tracking and feature request database? This would be a useful way to distribute work and to sync up contributors. I think the kernel uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.
>>>
>>> I'd like to contribute in some way. I've been having a lot of fun as a Xenomai user.
>>>
>> We don't have that unfortunately. As suggested by several posters,
>> moving to a git-based, integrated development framework such as gitlab
>> or github would bring in that feature, and others we need too (CI).
>>
>> I have no issue moving the project from the current git server at
>> xenomai.org to any of these environments.
>>
> 
> If it helps the community to grow, I would not refuse such a move. But I
> would like to raise some concerns about platforms like github or gitlab
> that we must be aware of:
> 
> - lacking integration with email-based workflows (while kernel
>   development tends to be based on that...)
> 
> - risk of decoupling communities when parts of the discussions happen on
>   tickets or PRs and parts in mailing list threads
> 
> Therefore, most projects I manage on github and in our internal gitlab
> have clear policies like "no emails, only tickets and PRs" or "no PRs,
> only patches on the mailing list". Even just using the issue tracker to
> keep some to-do list requires discipline to direct discussions
> consequently to a mailing list if that exists as well (and that usually
> does not work very well).
> 
> IOW: we need to be clear in what we want a platform for - and what not.
> 

Forking the original thread to get input from the list specifically
regarding the idea of moving GIT services from xenomai.org to a public
software development platform.

As Jan mentioned, there is more than having GIT underneath, there are
deep implications on the workflow, and it really depends on what we'd
want from such platform. If you have any thought, recommendation,
experience with those platforms in your daily work, it would be great to
know your views.

Thanks,

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Henning Schild]

Am Wed, 22 Nov 2017 21:26:23 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 2017-11-21 18:11, Philippe Gerum wrote:
> > So, let's talk about the elephant in the room: the current
> > situation of the Xenomai project is not viable in the long run. I
> > can only encourage people who feel concerned about it to discuss
> > openly the practical steps to best address this challenge.  
> 
> Thanks for bringing this frankly on the table! For those who follow
> the project, it's likely no news. So we were working on this issue
> also internally, with users of Xenomai inside Siemens. And we have the
> backing to enhance our involvement in upstream work. Right now we are
> working on making this concrete.

I could not agree more, thanks for bringing that up!

I will also be frank and put my thoughts on the table. The most
important point on our tasks to work on is culture. Technical details
and who does what can be addressed later or along the way.

IMHO Xenomai is not an open-source project. There is no open agenda, no
TODO list, issue tracking, discussions etc. All this critical
information, along with the hardcore technical details, used to be in
the heads of two people + plus a few others guessing and helping out a
bit. Now we are down to 1 + for quite a while. Still very much top-down
instead of open.

Looking at the project today nobody could tell where to start
contributing. Nobody knows when the next branch will pop up in git or
the next release will fall from the sky. Such things are not discussed,
they just happen.

Ok, now that was me expressing personal opinions and impressions, not
addressing blame.

I am convinced that a lot of this information can be opened up, maybe
with the use of tools (issue trackers etc.). Now for the experience and
the skills we desperately need Philippe to change his role to being
more of a mentor. And i will be happy to work on tasks that are
assigned to me, my solutions will lack speed and quality at first but
that will hopefully change over time.
 
> There are many areas where contributions can be beneficial for the
> project and its community, and many do not require deepest
> understanding of the core, like around CI, test automation, distro
> packaging, documentation, or user support. But some essential
> elements in my eyes are
> 
>  - building up a core team of kernel maintainers for Cobalt
> 
>  - offloading work from the shoulders of our extremely valuable
>    maintainer

We (Siemens) can help with 1 and therefore 2. ...for now. But adding a
few people to the inner circle will not do the trick. Especially not if
these people are coming from industry and only one player. The
dedication/funding of industry players by enlarge depends on business
decisions that are valid for one fiscal year.
But industry is the largest user of xenomai, so to mitigate that
problem more players are needed!

> The second part will be achieved to a certain degree by the first one
> as Philippe can probably confirm. So I would like to focus this and
> try to make some first step:
> 
> We are currently planning a so far internal workshop with Philippe in
> order to discuss how to bring more of our people but also others on
> board regarding kernel maintenance topics. Topics to discussed are
> likely
> 
>  - current design and how to introduce people to it (tough, yeah...)
>  - possible workflows and integration paths
>  - update strategy and frequency
>  - testing needs and strategies
>  - supportable architectures
>  - state and details of the new pipeline design
>  - planning of and migration path to the new design
> 
> If there is interest in joining such a discussion, physically (will
> likely take place in our office in Munich, Germany) or virtually
> (provided time zones work out), please let us know. Time frame is more
> likely early next year than mid of this December. And this shall be
> only the kickoff for further discussions in the community!

Yes, anyone that wants to join such a meeting please let us know.
Depending on the feedback we could also arrange something different.
(i.e. collocated with FOSDEM18? )

Henning

> Jan
> 

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jorge Ramirez]

On 11/23/2017 12:42 PM, Philippe Gerum wrote:
> On 11/22/2017 09:27 PM, Jan Kiszka wrote:
>> On 2017-11-22 16:32, Philippe Gerum wrote:
>>> Hi Kendall,
>>>
>>> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>>>> Hi Philippe,
>>>>
>>>> Is there an online bug tracking and feature request database? This would be a useful way to distribute work and to sync up contributors. I think the kernel uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.
>>>>
>>>> I'd like to contribute in some way. I've been having a lot of fun as a Xenomai user.
>>>>
>>> We don't have that unfortunately. As suggested by several posters,
>>> moving to a git-based, integrated development framework such as gitlab
>>> or github would bring in that feature, and others we need too (CI).
>>>
>>> I have no issue moving the project from the current git server at
>>> xenomai.org to any of these environments.
>>>
>> If it helps the community to grow, I would not refuse such a move. But I
>> would like to raise some concerns about platforms like github or gitlab
>> that we must be aware of:
>>
>> - lacking integration with email-based workflows (while kernel
>>    development tends to be based on that...)
>>
>> - risk of decoupling communities when parts of the discussions happen on
>>    tickets or PRs and parts in mailing list threads
>>
>> Therefore, most projects I manage on github and in our internal gitlab
>> have clear policies like "no emails, only tickets and PRs" or "no PRs,
>> only patches on the mailing list". Even just using the issue tracker to
>> keep some to-do list requires discipline to direct discussions
>> consequently to a mailing list if that exists as well (and that usually
>> does not work very well).
>>
>> IOW: we need to be clear in what we want a platform for - and what not.
>>
> Forking the original thread to get input from the list specifically
> regarding the idea of moving GIT services from xenomai.org to a public
> software development platform.
>
> As Jan mentioned, there is more than having GIT underneath, there are
> deep implications on the workflow, and it really depends on what we'd
> want from such platform. If you have any thought, recommendation,
> experience with those platforms in your daily work, it would be great to
> know your views.

In the past year alone I have been contributing to uboot (as board 
maintainer), arm-trusted-firmware (board maintainer), ffmpeg (v4l2 
support), zephyr (multiple drivers), the linux kernel (some fixes), AOSP 
(fixes) and a few others. So I have gained certain exposure to a number 
of workflows.

with this in mind I think the Zephyr workflow would suit Xenomai nicely.

It spins around Github and integrates with Shippable - this means that 
on each pull request, we can trigger a full rebuild and run sanity and 
maybe even performance tests before any code review can begin; the 
subsystem maintainer/s then can review the pull request adding comments 
on the code as it moves along.

Xenomai also lacks an IRC channel which makes things way too quiet for a 
small size community (in the case of ffmpeg for instance IRC is where 
most if not all the discussions happen). IRC is - and should be for 
Xenomai- a good place to ask for help and direction. So I vote for 
having one.

To sum up, given the low rate of patches that Xenomai handles and given 
the need push back on performance degradation I strongly believe that 
the Zephyr's workflow would work for us. The way performance 
ramifications are maintained today is pretty much living in Philippe's 
and possibly Jan's head: I think we should move from intuition to 
explicit measurable data when merging PRs (ie, establishing a 
multi-board CI loop)

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Henning Schild]

Am Thu, 23 Nov 2017 12:42:08 +0100
schrieb Philippe Gerum <rpm@xenomai.org>:

> On 11/22/2017 09:27 PM, Jan Kiszka wrote:
> > On 2017-11-22 16:32, Philippe Gerum wrote:  
> >>
> >> Hi Kendall,
> >>
> >> On 11/21/2017 08:27 PM, Auel, Kendall wrote:  
> >>> Hi Philippe,
> >>>
> >>> Is there an online bug tracking and feature request database?
> >>> This would be a useful way to distribute work and to sync up
> >>> contributors. I think the kernel uses Bugzilla, and Ubuntu has
> >>> Launchpad. No doubt there are many others.
> >>>
> >>> I'd like to contribute in some way. I've been having a lot of fun
> >>> as a Xenomai user. 
> >> We don't have that unfortunately. As suggested by several posters,
> >> moving to a git-based, integrated development framework such as
> >> gitlab or github would bring in that feature, and others we need
> >> too (CI).
> >>
> >> I have no issue moving the project from the current git server at
> >> xenomai.org to any of these environments.
> >>  
> > 
> > If it helps the community to grow, I would not refuse such a move.
> > But I would like to raise some concerns about platforms like github
> > or gitlab that we must be aware of:
> > 
> > - lacking integration with email-based workflows (while kernel
> >   development tends to be based on that...)
> > 
> > - risk of decoupling communities when parts of the discussions
> > happen on tickets or PRs and parts in mailing list threads
> > 
> > Therefore, most projects I manage on github and in our internal
> > gitlab have clear policies like "no emails, only tickets and PRs"
> > or "no PRs, only patches on the mailing list". Even just using the
> > issue tracker to keep some to-do list requires discipline to direct
> > discussions consequently to a mailing list if that exists as well
> > (and that usually does not work very well).
> > 
> > IOW: we need to be clear in what we want a platform for - and what
> > not. 
> 
> Forking the original thread to get input from the list specifically
> regarding the idea of moving GIT services from xenomai.org to a public
> software development platform.
> 
> As Jan mentioned, there is more than having GIT underneath, there are
> deep implications on the workflow, and it really depends on what we'd
> want from such platform. If you have any thought, recommendation,
> experience with those platforms in your daily work, it would be great
> to know your views.

Jan is absolutely right here. Before moving to github (or something
alike) you need to set groundrules for how to deal with PRs, issues and
all the stuff that you suddenly gain.

I think Xenomai could benefit from issue tracking and CI, not sure
whether we need github for that. The CI they offer is docker-based and
we would likely want something more powerful. But i guess you could
always use docker to remote control AWS or real hardware.

github sucks at routing mails. My github account is shared between my
work and personal stuff but i do not star/watch any work related
projects because i do not want the notifications in my personal inbox.

commitment to github etc. is likely to cause sort of a vendor lock-in.
I am sure the APIs can be used to extract some information, but will you
get something that you can import into your own gitlab or track later
on? As long as we only use git-hosting and CI from them that would not
be too much of a problem.

Henning

> Thanks,
> 

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jorge Ramirez]

On 11/23/2017 01:52 PM, Henning Schild wrote:
> Am Thu, 23 Nov 2017 12:42:08 +0100
> schrieb Philippe Gerum <rpm@xenomai.org>:
>
>> On 11/22/2017 09:27 PM, Jan Kiszka wrote:
>>> On 2017-11-22 16:32, Philippe Gerum wrote:
>>>> Hi Kendall,
>>>>
>>>> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>>>>> Hi Philippe,
>>>>>
>>>>> Is there an online bug tracking and feature request database?
>>>>> This would be a useful way to distribute work and to sync up
>>>>> contributors. I think the kernel uses Bugzilla, and Ubuntu has
>>>>> Launchpad. No doubt there are many others.
>>>>>
>>>>> I'd like to contribute in some way. I've been having a lot of fun
>>>>> as a Xenomai user.
>>>> We don't have that unfortunately. As suggested by several posters,
>>>> moving to a git-based, integrated development framework such as
>>>> gitlab or github would bring in that feature, and others we need
>>>> too (CI).
>>>>
>>>> I have no issue moving the project from the current git server at
>>>> xenomai.org to any of these environments.
>>>>   
>>> If it helps the community to grow, I would not refuse such a move.
>>> But I would like to raise some concerns about platforms like github
>>> or gitlab that we must be aware of:
>>>
>>> - lacking integration with email-based workflows (while kernel
>>>    development tends to be based on that...)
>>>
>>> - risk of decoupling communities when parts of the discussions
>>> happen on tickets or PRs and parts in mailing list threads
>>>
>>> Therefore, most projects I manage on github and in our internal
>>> gitlab have clear policies like "no emails, only tickets and PRs"
>>> or "no PRs, only patches on the mailing list". Even just using the
>>> issue tracker to keep some to-do list requires discipline to direct
>>> discussions consequently to a mailing list if that exists as well
>>> (and that usually does not work very well).
>>>
>>> IOW: we need to be clear in what we want a platform for - and what
>>> not.
>> Forking the original thread to get input from the list specifically
>> regarding the idea of moving GIT services from xenomai.org to a public
>> software development platform.
>>
>> As Jan mentioned, there is more than having GIT underneath, there are
>> deep implications on the workflow, and it really depends on what we'd
>> want from such platform. If you have any thought, recommendation,
>> experience with those platforms in your daily work, it would be great
>> to know your views.
> Jan is absolutely right here. Before moving to github (or something
> alike) you need to set groundrules for how to deal with PRs, issues and
> all the stuff that you suddenly gain.
>
> I think Xenomai could benefit from issue tracking and CI, not sure
> whether we need github for that.

issue tracking is not something that important IMO.
I dont believe this is extensively used by any projects but mainly distros.

> The CI they offer is docker-based and
> we would likely want something more powerful. But i guess you could
> always use docker to remote control AWS or real hardware.

yes. there are a number of solutions that in fact do OTA and most of 
them use Docker to control real hardware.
the industry seems to be going in that direction. I think Shippable 
should server our purpose.

for instance, check out this commit:
https://github.com/zephyrproject-rtos/zephyr/pull/5134

and its shippable output
https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/7471/summary/console

> github sucks at routing mails. My github account is shared between my
> work and personal stuff but i do not star/watch any work related
> projects because i do not want the notifications in my personal inbox.

I agree that it sucks but I dont see why this should be an issue.
Just dont rely on github emails (I personally tend to disable them, they 
are extremely annoying).

when I need to find out how any PR is progressing (every other day) I 
just connect to github.

>
> commitment to github etc. is likely to cause sort of a vendor lock-in.

? what do you mean?
> I am sure the APIs can be used to extract some information, but will you
> get something that you can import into your own gitlab or track later
> on? As long as we only use git-hosting and CI from them that would not
> be too much of a problem.

yeah everything can be done (ie: at linaro we have lava-labs and 
integrate our own CI loops with Jenkins and real hardware).
But I dont believe Xenomai has the dedicated resources for that.

BTW at ELCE in Prague, Tgx's daughter presented a very interesting 
approach [1] to accessing real hardware on CI (using libvirt). Very cool.
I think we should use it if in the end we decide to roll our own. But 
IMO, Shippable should suffice.

[1] 
https://osseu17.sched.com/event/ByYA/continuous-integration-jenkins-libvirt-and-real-hardware-anna-maria-gleixner-manuel-traut-linutronix-gmbh


>
> Henning
>
>> Thanks,
>>
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Giulio Moro]

At Bela (bela.io) we use Xenomai on the BeagleBone Black for audio. Currently our resources are pretty scarce, but hopefully from March things should get better For instance, now that RobertCNelson has discontinued support for Xenomai on the BeagleBone, we may be able to help with that (incidentally - as someone was asking - we provide a pre-built image for BeagleBone with Debian Stretch and  Xenomai 3.0.5 on Linux 4.4 (and some of our stuff too): https://github.com//BelaPlatform/bela-image-builder/releases).

> We are currently planning a so far internal workshop with Philippe in
> order to discuss how to bring more of our people but also others on
> board regarding kernel maintenance topics. Topics to discussed are
> likely

Either way, it would be great to be able to take part in this workshop with Philippe. I think it is unlikely that we would be able to travel to Munich in January, but we should be able to attend remotely, so please keep us in the loop. I reckon it would be important (if all the involved parties agree, that is) to make a video recording of the workshop available online for posterity (e.g.: a youtube live streaming and subsequently available permanently), so to make it easier for others in the future to get started with Xenomai's development.

Thanks,
Giulio

________________________________________
From: Xenomai <xenomai-bounces@xenomai.org> on behalf of Henning Schild <henning.schild@siemens.com>
Sent: 23 November 2017 12:21
To: Jan Kiszka
Cc: Daniel Wagner; Xenomai@xenomai.org
Subject: Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

Am Wed, 22 Nov 2017 21:26:23 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 2017-11-21 18:11, Philippe Gerum wrote:
> > So, let's talk about the elephant in the room: the current
> > situation of the Xenomai project is not viable in the long run. I
> > can only encourage people who feel concerned about it to discuss
> > openly the practical steps to best address this challenge.
>
> Thanks for bringing this frankly on the table! For those who follow
> the project, it's likely no news. So we were working on this issue
> also internally, with users of Xenomai inside Siemens. And we have the
> backing to enhance our involvement in upstream work. Right now we are
> working on making this concrete.

I could not agree more, thanks for bringing that up!

I will also be frank and put my thoughts on the table. The most
important point on our tasks to work on is culture. Technical details
and who does what can be addressed later or along the way.

IMHO Xenomai is not an open-source project. There is no open agenda, no
TODO list, issue tracking, discussions etc. All this critical
information, along with the hardcore technical details, used to be in
the heads of two people + plus a few others guessing and helping out a
bit. Now we are down to 1 + for quite a while. Still very much top-down
instead of open.

Looking at the project today nobody could tell where to start
contributing. Nobody knows when the next branch will pop up in git or
the next release will fall from the sky. Such things are not discussed,
they just happen.

Ok, now that was me expressing personal opinions and impressions, not
addressing blame.

I am convinced that a lot of this information can be opened up, maybe
with the use of tools (issue trackers etc.). Now for the experience and
the skills we desperately need Philippe to change his role to being
more of a mentor. And i will be happy to work on tasks that are
assigned to me, my solutions will lack speed and quality at first but
that will hopefully change over time.

> There are many areas where contributions can be beneficial for the
> project and its community, and many do not require deepest
> understanding of the core, like around CI, test automation, distro
> packaging, documentation, or user support. But some essential
> elements in my eyes are
>
>  - building up a core team of kernel maintainers for Cobalt
>
>  - offloading work from the shoulders of our extremely valuable
>    maintainer

We (Siemens) can help with 1 and therefore 2. ...for now. But adding a
few people to the inner circle will not do the trick. Especially not if
these people are coming from industry and only one player. The
dedication/funding of industry players by enlarge depends on business
decisions that are valid for one fiscal year.
But industry is the largest user of xenomai, so to mitigate that
problem more players are needed!

> The second part will be achieved to a certain degree by the first one
> as Philippe can probably confirm. So I would like to focus this and
> try to make some first step:
>
> We are currently planning a so far internal workshop with Philippe in
> order to discuss how to bring more of our people but also others on
> board regarding kernel maintenance topics. Topics to discussed are
> likely
>
>  - current design and how to introduce people to it (tough, yeah...)
>  - possible workflows and integration paths
>  - update strategy and frequency
>  - testing needs and strategies
>  - supportable architectures
>  - state and details of the new pipeline design
>  - planning of and migration path to the new design
>
> If there is interest in joining such a discussion, physically (will
> likely take place in our office in Munich, Germany) or virtually
> (provided time zones work out), please let us know. Time frame is more
> likely early next year than mid of this December. And this shall be
> only the kickoff for further discussions in the community!

Yes, anyone that wants to join such a meeting please let us know.
Depending on the feedback we could also arrange something different.
(i.e. collocated with FOSDEM18? )

Henning

> Jan
>


_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jan Kiszka]

On 2017-11-23 14:18, Jorge Ramirez wrote:
> On 11/23/2017 01:52 PM, Henning Schild wrote:
>> Am Thu, 23 Nov 2017 12:42:08 +0100
>> schrieb Philippe Gerum <rpm@xenomai.org>:
>>
>>> On 11/22/2017 09:27 PM, Jan Kiszka wrote:
>>>> On 2017-11-22 16:32, Philippe Gerum wrote:
>>>>> Hi Kendall,
>>>>>
>>>>> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>>>>>> Hi Philippe,
>>>>>>
>>>>>> Is there an online bug tracking and feature request database?
>>>>>> This would be a useful way to distribute work and to sync up
>>>>>> contributors. I think the kernel uses Bugzilla, and Ubuntu has
>>>>>> Launchpad. No doubt there are many others.
>>>>>>
>>>>>> I'd like to contribute in some way. I've been having a lot of fun
>>>>>> as a Xenomai user.
>>>>> We don't have that unfortunately. As suggested by several posters,
>>>>> moving to a git-based, integrated development framework such as
>>>>> gitlab or github would bring in that feature, and others we need
>>>>> too (CI).
>>>>>
>>>>> I have no issue moving the project from the current git server at
>>>>> xenomai.org to any of these environments.
>>>>>   
>>>> If it helps the community to grow, I would not refuse such a move.
>>>> But I would like to raise some concerns about platforms like github
>>>> or gitlab that we must be aware of:
>>>>
>>>> - lacking integration with email-based workflows (while kernel
>>>>    development tends to be based on that...)
>>>>
>>>> - risk of decoupling communities when parts of the discussions
>>>> happen on tickets or PRs and parts in mailing list threads
>>>>
>>>> Therefore, most projects I manage on github and in our internal
>>>> gitlab have clear policies like "no emails, only tickets and PRs"
>>>> or "no PRs, only patches on the mailing list". Even just using the
>>>> issue tracker to keep some to-do list requires discipline to direct
>>>> discussions consequently to a mailing list if that exists as well
>>>> (and that usually does not work very well).
>>>>
>>>> IOW: we need to be clear in what we want a platform for - and what
>>>> not.
>>> Forking the original thread to get input from the list specifically
>>> regarding the idea of moving GIT services from xenomai.org to a public
>>> software development platform.
>>>
>>> As Jan mentioned, there is more than having GIT underneath, there are
>>> deep implications on the workflow, and it really depends on what we'd
>>> want from such platform. If you have any thought, recommendation,
>>> experience with those platforms in your daily work, it would be great
>>> to know your views.
>> Jan is absolutely right here. Before moving to github (or something
>> alike) you need to set groundrules for how to deal with PRs, issues and
>> all the stuff that you suddenly gain.
>>
>> I think Xenomai could benefit from issue tracking and CI, not sure
>> whether we need github for that.
> 
> issue tracking is not something that important IMO.
> I dont believe this is extensively used by any projects but mainly distros.
> 
>> The CI they offer is docker-based and
>> we would likely want something more powerful. But i guess you could
>> always use docker to remote control AWS or real hardware.
> 
> yes. there are a number of solutions that in fact do OTA and most of
> them use Docker to control real hardware.
> the industry seems to be going in that direction. I think Shippable
> should server our purpose.
> 
> for instance, check out this commit:
> https://github.com/zephyrproject-rtos/zephyr/pull/5134
> 
> and its shippable output
> https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/7471/summary/console
> 

Shippable looks interesting. We are working internally with gitlab-ci
and for several public projects with Travis. But the free services are
usually nothing for "serious" workload like kernel builds because they
either lack powerful builders or have limits on the job length - or both
which doesn't make it better. For Jailhouse, I worked around that in
Travis by caching the required kernel build.

Do you know what limits exist in shippable?

> 
>> github sucks at routing mails. My github account is shared between my
>> work and personal stuff but i do not star/watch any work related
>> projects because i do not want the notifications in my personal inbox.
> 
> I agree that it sucks but I dont see why this should be an issue.
> Just dont rely on github emails (I personally tend to disable them, they
> are extremely annoying).
> 
> when I need to find out how any PR is progressing (every other day) I
> just connect to github.

It's a personal thing, but web UIs do not scale for me. I'm on way too
many platforms, and all suck at least a little bit in certain ways. But
then, when you then need to combine them to keep track, the problem
becomes serious because email do not work for most of them. Again, a
personal issue I just happen to share with many kernel hackers.

In the end, the platform we pick depends on the group of developers we
want to attract. If the majority of our key contributors and maintainers
become more productive for the project in a specific way, pick that one.
But be careful with choices that cannot be changed again easily.

> 
>>
>> commitment to github etc. is likely to cause sort of a vendor lock-in.
> 
> ? what do you mean?
>> I am sure the APIs can be used to extract some information, but will you
>> get something that you can import into your own gitlab or track later
>> on? As long as we only use git-hosting and CI from them that would not
>> be too much of a problem.
> 
> yeah everything can be done (ie: at linaro we have lava-labs and
> integrate our own CI loops with Jenkins and real hardware).
> But I dont believe Xenomai has the dedicated resources for that.
> 
> BTW at ELCE in Prague, Tgx's daughter presented a very interesting
> approach [1] to accessing real hardware on CI (using libvirt). Very cool.
> I think we should use it if in the end we decide to roll our own. But
> IMO, Shippable should suffice.
> 
> [1]
> https://osseu17.sched.com/event/ByYA/continuous-integration-jenkins-libvirt-and-real-hardware-anna-maria-gleixner-manuel-traut-linutronix-gmbh
> 

FWIW, collaboration projects like Automotive Grade Linux or our Civil
Infrastructure Platform are significantly investing into LAVA now. And
we also do this here internally. We are not yet at a point where we can
easily spawn and/or scale out labs, but that time will come. It's an
industry trend regarding collaborative testing right now, and I'm sure
we will eventually be able to exploit it for Xenomai as well.

But let's focus on CI first. Then maybe easily retrievable test images
for your manually operated test lab.

Jan

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

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/22/2017 09:27 PM, Jan Kiszka wrote:
> On 2017-11-22 16:32, Philippe Gerum wrote:
>>
>> Hi Kendall,
>>
>> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>>> Hi Philippe,
>>>
>>> Is there an online bug tracking and feature request database? This would be a useful way to distribute work and to sync up contributors. I think the kernel uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.
>>>
>>> I'd like to contribute in some way. I've been having a lot of fun as a Xenomai user.
>>>
>> We don't have that unfortunately. As suggested by several posters,
>> moving to a git-based, integrated development framework such as gitlab
>> or github would bring in that feature, and others we need too (CI).
>>
>> I have no issue moving the project from the current git server at
>> xenomai.org to any of these environments.
>>
> 
> If it helps the community to grow, I would not refuse such a move. But I
> would like to raise some concerns about platforms like github or gitlab
> that we must be aware of:
> 
> - lacking integration with email-based workflows (while kernel
>   development tends to be based on that...)
> 
> - risk of decoupling communities when parts of the discussions happen on
>   tickets or PRs and parts in mailing list threads
> 
> Therefore, most projects I manage on github and in our internal gitlab
> have clear policies like "no emails, only tickets and PRs" or "no PRs,
> only patches on the mailing list". Even just using the issue tracker to
> keep some to-do list requires discipline to direct discussions
> consequently to a mailing list if that exists as well (and that usually
> does not work very well).
> 
> IOW: we need to be clear in what we want a platform for - and what not.
> 

Defining the process first may help, then we could certainly find a tool
that fits the requirement. AFAICT, reports from users and maintainers
mainly fall into these categories:

- perceived runtime bugs (confirmed or not)
- configuration, installation problems
- request for change, improvements

Reports about runtime bugs should be posted to mailing list first,
unless they have been directly observed by a subsystem maintainer. If
the issue is confirmed, it should be logged into the tracker by the
concerned subsystem maintainer. Many users report bugs which have
already been solved, the tracker should help making the solution visible
for closed issues, or maybe we'd need another way to bring up that
information to the attention of users.

Request for changes should translate into RFCs to the mailing list so
they can be discussed, last but not least to prevent duplicate effort
with potentially ongoing work. A detailed description of what is
needed/planned could then be published to a dedicated section of the web
site in free form; this would contribute to the general TODO list Greg
mentioned earlier.

Questions about configuration and installation can be efficiently dealt
with good documentation (TBD) and a mailing list.

To get this process working, I don't think we'd need more than a tracker
with write access to subsystem maintainers only (once we have some, that
is), and the existing mailing list, which should prevent crosstalk.

-- 
Philippe.

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Lennart Sorensen]

On Thu, Nov 23, 2017 at 01:38:03PM +0100, Jorge Ramirez wrote:
> In the past year alone I have been contributing to uboot (as board
> maintainer), arm-trusted-firmware (board maintainer), ffmpeg (v4l2 support),
> zephyr (multiple drivers), the linux kernel (some fixes), AOSP (fixes) and a
> few others. So I have gained certain exposure to a number of workflows.
> 
> with this in mind I think the Zephyr workflow would suit Xenomai nicely.

I personally like the linux kernel workflow where everything is through
a mailing list and patches are reviewed before they go in.  I am not
sure that workflow would work for xenomai, but I do like it.

> It spins around Github and integrates with Shippable - this means that on
> each pull request, we can trigger a full rebuild and run sanity and maybe
> even performance tests before any code review can begin; the subsystem
> maintainer/s then can review the pull request adding comments on the code as
> it moves along.

I am not sure build tests are that useful given the number of different
platforms the code runs on.  Which one do you build test for?

> Xenomai also lacks an IRC channel which makes things way too quiet for a
> small size community (in the case of ffmpeg for instance IRC is where most
> if not all the discussions happen). IRC is - and should be for Xenomai- a
> good place to ask for help and direction. So I vote for having one.

IRC is useless when the community is small and spread across timezones.
At least with the mailing list people will see the question and can
answer it when it hits their timezone.  IRC isn't helpful when no one
is there to read your question when you write it.  And good luck trying
to convey anything complex in an IRC conversation.  Want to try sending
source code patches through IRC for discussion?

I check my email daily.  I don't check random websites daily to check
the forums for project x, y and z each with a different interface.
Too much work.

> To sum up, given the low rate of patches that Xenomai handles and given the
> need push back on performance degradation I strongly believe that the
> Zephyr's workflow would work for us. The way performance ramifications are
> maintained today is pretty much living in Philippe's and possibly Jan's
> head: I think we should move from intuition to explicit measurable data when
> merging PRs (ie, establishing a multi-board CI loop)

-- 
Len Sorensen

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Philippe Gerum]

On 11/23/2017 01:38 PM, Jorge Ramirez wrote:
> Xenomai also lacks an IRC channel which makes things way too quiet for a
> small size community (in the case of ffmpeg for instance IRC is where
> most if not all the discussions happen). IRC is - and should be for
> Xenomai- a good place to ask for help and direction. So I vote for
> having one.
> 

IRC may be intrusive to some people, as it is by design preempting one's
attention unlike e-mail. This might work if a sufficient number of
people is actually willing to help on the channel though. Maybe.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/22/2017 09:26 PM, Jan Kiszka wrote:
> On 2017-11-21 18:11, Philippe Gerum wrote:
>> So, let's talk about the elephant in the room: the current situation of
>> the Xenomai project is not viable in the long run. I can only encourage
>> people who feel concerned about it to discuss openly the practical steps
>> to best address this challenge.
> 
> Thanks for bringing this frankly on the table! For those who follow the
> project, it's likely no news. So we were working on this issue also
> internally, with users of Xenomai inside Siemens. And we have the
> backing to enhance our involvement in upstream work. Right now we are
> working on making this concrete.
> 
> There are many areas where contributions can be beneficial for the
> project and its community, and many do not require deepest understanding
> of the core, like around CI, test automation, distro packaging,
> documentation, or user support. But some essential elements in my eyes are
> 
>  - building up a core team of kernel maintainers for Cobalt
> 
>  - offloading work from the shoulders of our extremely valuable
>    maintainer
> 
> The second part will be achieved to a certain degree by the first one as
> Philippe can probably confirm.

Yes, extending "Cobalt" to the pipeline. A significant portion of the
overall maintenance involves the I-pipe. Hence the work on rethinking
how the interrupt pipeline is integrated into the Linux kernel, how we
can make the former a regular feature of the latter instead of an
add-on, with the goal of simplifying the maintenance, but also making
the whole thing way more natural, easier to grasp.

-- 
Philippe.

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jorge Ramirez]

On 11/23/2017 09:36 PM, Philippe Gerum wrote:
> On 11/23/2017 01:38 PM, Jorge Ramirez wrote:
>> Xenomai also lacks an IRC channel which makes things way too quiet for a
>> small size community (in the case of ffmpeg for instance IRC is where
>> most if not all the discussions happen). IRC is - and should be for
>> Xenomai- a good place to ask for help and direction. So I vote for
>> having one.
>>
> IRC may be intrusive to some people, as it is by design preempting one's
> attention unlike e-mail. This might work if a sufficient number of
> people is actually willing to help on the channel though. Maybe.
>

IRC notifications can be ignored just like any others (you can just 
listen to certain nicks or keys as most users do)
There are pretty decent tools these days. (as an example I follow ten to 
twenty channels and it is not that bad).

I understand the point of not having a sufficient number of people 
willing - maybe capable is a better word?- to help (core knowledge today 
is pretty much concentrated in yourself which is issue #1).
But the way I see it an IRC channel should be a step towards removing 
that issue - those that tend/need to spend more time working with 
Xenomai (maybe developing a product) will end up driving the channel. 
And that is something that I think is needed.

And clearly IRC doesnt replace mailing lists: these are different tools 
for difference use cases.

I think the tools that we provide will end up shaping the community that 
we will have.
To me, not having a channel is an issue. You kind of pointed out that 
the channel -at least at the beginning- will probably just be many 
questions and little answers.

But maybe not? there are many products out there using Xenomai so who 
knows.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane LOS]

Hi,

Wouldn't integrating both projects make sense ?

It seems both share a significant amount of work and similar lack of 
resources.

Best Regards,
Cordialement,

Stéphane LOS
slos@hilscher.com
Support technique

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hilscher France
12, rue du 35ème Régiment d'Aviation
Miniparc du Chêne
69500 BRON
France
Tél. : +33 (0) 4 72 37 98 40
Fax  : +33 (0) 4 78 26 83 27
http ://www.hilscher.fr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Le 23/11/2017 à 21:45, Philippe Gerum a écrit :
> On 11/22/2017 09:26 PM, Jan Kiszka wrote:
>> On 2017-11-21 18:11, Philippe Gerum wrote:
>>> So, let's talk about the elephant in the room: the current situation of
>>> the Xenomai project is not viable in the long run. I can only encourage
>>> people who feel concerned about it to discuss openly the practical steps
>>> to best address this challenge.
>> Thanks for bringing this frankly on the table! For those who follow the
>> project, it's likely no news. So we were working on this issue also
>> internally, with users of Xenomai inside Siemens. And we have the
>> backing to enhance our involvement in upstream work. Right now we are
>> working on making this concrete.
>>
>> There are many areas where contributions can be beneficial for the
>> project and its community, and many do not require deepest understanding
>> of the core, like around CI, test automation, distro packaging,
>> documentation, or user support. But some essential elements in my eyes are
>>
>>   - building up a core team of kernel maintainers for Cobalt
>>
>>   - offloading work from the shoulders of our extremely valuable
>>     maintainer
>>
>> The second part will be achieved to a certain degree by the first one as
>> Philippe can probably confirm.
> Yes, extending "Cobalt" to the pipeline. A significant portion of the
> overall maintenance involves the I-pipe. Hence the work on rethinking
> how the interrupt pipeline is integrated into the Linux kernel, how we
> can make the former a regular feature of the latter instead of an
> add-on, with the goal of simplifying the maintenance, but also making
> the whole thing way more natural, easier to grasp.
>



Hilscher France S.a.r.l.   |  12, rue du 35ième Régiment d’Aviation – Miniparc du Chêne  |  69500 Bron  |  France  |  www.hilscher.com
Hot Line: +33 (0) 472 379 843  |  Centre de formation agréé  |  RandD: +33 (0) 472 379 840
N° de TVA intracommunautaire: FR 43 449 481 779  |  N° de SIRET: 449 481 779 00014
Dirigeant: Christophe Levra

Important Information:
This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.

Hilscher cannot be held responsible of whatever nature, resulting from alteration, falsifying or using of the information contained in this message and disclaims all liability in case of contamination of the computer hardware of the addressee resulting from the distribution of a virus or other computing infections.


Information Importante:
Ce message électronique incluant les pièces jointes contient des informations confidentielles et protégées par la loi qui sont à l’intention exclusive de son destinataire. Si vous n'êtes pas le destinataire  de ce message, merci de contactez immédiatement l'expéditeur et de supprimer ce message incluant les pièces jointes. Toute diffusion ou copie ou modification de ce message électronique, totale ou partielle, non autorisée est strictement interdit. L'expéditeur ne peut être tenu responsable du contenu de tels messages électroniques qui auraient été modifies.

Hilscher ne pourra être tenue responsable de quelque dommage, de quelque nature qu’il soit, résultant de l’altération, de la falsification ou de l’utilisation des informations contenues dans ce message et décline toute responsabilité en cas de contamination des matériels informatiques du destinataire résultant de la propagation d'un virus ou autres infections informatiques.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane LOS]

Hi,

Wouldn't integrating both projects make sense ?

It seems both share a significant amount of work and similar lack of 
resources.

Sorry, talking about the "Real Time Linux" project and "Xenomai"...

And sorry for the noise added automagically to my emails. :-(
I should use some other mail account.

Best Regards,
Cordialement,

Stéphane LOS
slos@hilscher.com
Support technique

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hilscher France
12, rue du 35ème Régiment d'Aviation
Miniparc du Chêne
69500 BRON
France
Tél. : +33 (0) 4 72 37 98 40
Fax  : +33 (0) 4 78 26 83 27
http ://www.hilscher.fr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Le 24/11/2017 à 09:52, Stéphane LOS a écrit :
> Hi,
>
> Wouldn't integrating both projects make sense ?
>
> It seems both share a significant amount of work and similar lack of 
> resources.
>
> Best Regards,
> Cordialement,
>
> Stéphane LOS
> slos@hilscher.com
> Support technique
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Hilscher France
> 12, rue du 35ème Régiment d'Aviation
> Miniparc du Chêne
> 69500 BRON
> France
> Tél. : +33 (0) 4 72 37 98 40
> Fax  : +33 (0) 4 78 26 83 27
> http ://www.hilscher.fr
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Le 23/11/2017 à 21:45, Philippe Gerum a écrit :
>> On 11/22/2017 09:26 PM, Jan Kiszka wrote:
>>> On 2017-11-21 18:11, Philippe Gerum wrote:
>>>> So, let's talk about the elephant in the room: the current 
>>>> situation of
>>>> the Xenomai project is not viable in the long run. I can only 
>>>> encourage
>>>> people who feel concerned about it to discuss openly the practical 
>>>> steps
>>>> to best address this challenge.
>>> Thanks for bringing this frankly on the table! For those who follow the
>>> project, it's likely no news. So we were working on this issue also
>>> internally, with users of Xenomai inside Siemens. And we have the
>>> backing to enhance our involvement in upstream work. Right now we are
>>> working on making this concrete.
>>>
>>> There are many areas where contributions can be beneficial for the
>>> project and its community, and many do not require deepest 
>>> understanding
>>> of the core, like around CI, test automation, distro packaging,
>>> documentation, or user support. But some essential elements in my 
>>> eyes are
>>>
>>>   - building up a core team of kernel maintainers for Cobalt
>>>
>>>   - offloading work from the shoulders of our extremely valuable
>>>     maintainer
>>>
>>> The second part will be achieved to a certain degree by the first 
>>> one as
>>> Philippe can probably confirm.
>> Yes, extending "Cobalt" to the pipeline. A significant portion of the
>> overall maintenance involves the I-pipe. Hence the work on rethinking
>> how the interrupt pipeline is integrated into the Linux kernel, how we
>> can make the former a regular feature of the latter instead of an
>> add-on, with the goal of simplifying the maintenance, but also making
>> the whole thing way more natural, easier to grasp.
>>
>



Hilscher France S.a.r.l.   |  12, rue du 35ième Régiment d’Aviation – Miniparc du Chêne  |  69500 Bron  |  France  |  www.hilscher.com
Hot Line: +33 (0) 472 379 843  |  Centre de formation agréé  |  RandD: +33 (0) 472 379 840
N° de TVA intracommunautaire: FR 43 449 481 779  |  N° de SIRET: 449 481 779 00014
Dirigeant: Christophe Levra

Important Information:
This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.

Hilscher cannot be held responsible of whatever nature, resulting from alteration, falsifying or using of the information contained in this message and disclaims all liability in case of contamination of the computer hardware of the addressee resulting from the distribution of a virus or other computing infections.


Information Importante:
Ce message électronique incluant les pièces jointes contient des informations confidentielles et protégées par la loi qui sont à l’intention exclusive de son destinataire. Si vous n'êtes pas le destinataire  de ce message, merci de contactez immédiatement l'expéditeur et de supprimer ce message incluant les pièces jointes. Toute diffusion ou copie ou modification de ce message électronique, totale ou partielle, non autorisée est strictement interdit. L'expéditeur ne peut être tenu responsable du contenu de tels messages électroniques qui auraient été modifies.

Hilscher ne pourra être tenue responsable de quelque dommage, de quelque nature qu’il soit, résultant de l’altération, de la falsification ou de l’utilisation des informations contenues dans ce message et décline toute responsabilité en cas de contamination des matériels informatiques du destinataire résultant de la propagation d'un virus ou autres infections informatiques.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane Ancelot]

Hi guys,

Here at Numalliance, as xenomai development contributors and users, we 
can  give only a quick reply to some points at the moment :

Regarding irc/mailing lists , we would prefer tools like  Discord, that 
is a modern,very  good collaborative and interactive tool to discuss 
subjects.Using either text or voice channels.
You will not attract young people generation with IRC .

an issue tracker would be mandatory in order to :
* identify problems and permit resolution to anyone wanting  to 
contribute and solve it
* link issues with the software repository and resolution (back and 
forth) , (we are using redmine )
* history tracking

I know many opensource projects are using stackoverflow  as main website 
support  .
It permits knowledge sharing.
Questions/Replies  are often reviewed by other people and thus filtered 
if questions need clarifying or duplicated issues ...

The xenomai API is not enough documented in order to permit new 
developer's entry.
Targetting and permitting students to contribute could be a good benefit.

Unit tests cases seem mandatory .


Regards,
S.Ancelot

Le 21/11/2017 à 18:11, Philippe Gerum a écrit :
> As the GIT commit history shows, there has been no sustained effort in
> maintaining several of the Xenomai I/O frameworks for several months
> (e.g. RTnet, analogy), even years in some cases, despite obvious bugs
> are still haunting the code base according to the mailing list. The
> situation has reached a point where I see no alternative to dropping
> them if the situation does not improve, because there is absolutely no
> point in this project shipping bit rot software that won't ever be fixed.
>
> Unfortunately, this is only the tip of the iceberg. Let's face it, since
> Gilles passed away last year, I have not been scaling to the Xenomai
> maintenance, development and documentation tasks, with the requirement
> of running my business in parallel.
>
> The solution to this serious problem is fitting the project to the
> available resources by narrowing its goal, or conversely, by growing the
> pool of contributors.
>
> In addition, we can rework the most tricky part of the implementation to
> make it simpler to maintain, better documented, drastically lowering the
> barrier on entry for new contributors, which is what I've been working
> on for a year with the 4th generation of the interrupt pipeline.
> Progress on this front has been significant already, but once again
> limited by the time I have been able to devote to this development so far.
>
> For the past 16 years, this project has lived on various types of
> contributions from only a few committed people and companies. At this
> chance, let's mention that people who have been deploying Xenomai in
> industrial applications owe a lot to Wolfgang Denk from Denx
> Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported
> the project in crucial ways directly or indirectly over the years, and
> still do.
>
> Xenomai as a dual kernel technology showcase has been quietly delivering
> on the promise of real-time Linux for more than a decade now, with
> marketing tools limited to showing decent code quality, good and
> reliable performance figures. As a result, to my current knowledge,
> Xenomai is present in a broad range of applications and systems:
> magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> communication equipment, autonomous vehicles, control & automation
> systems in various plants.
>
> On the sad side of the story, this project has virtually become a
> one-man show the day Gilles - my long-time friend and hacking soul mate
> - left us. That show is too big for me to run it alone, which entails
> maintaining:
>
> - the interrupt pipeline for 7 CPU architectures
> - the Cobalt co-kernel
> - 4 APIs, plus the "copperplate" mediating layer
> - several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI, GPIO
> - the documentation (which is currently unfriendly to newcomers, and
> stalled two years ago or so)
> - the website
> - the testing and release processes
>
> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.
>
> Thanks,
>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/24/2017 11:46 AM, Stéphane Ancelot wrote:
> The xenomai API is not enough documented in order to permit new
> developer's entry.

Can you elaborate on what could be done to improve the documentation,
according to your own experience with it?

> Targetting and permitting students to contribute could be a good benefit.
>

How would you do that?

> Unit tests cases seem mandatory .
> 

There are (testsuite/smokey), but clearly not enough of them though.

-- 
Philippe.

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jorge Ramirez]

On 11/23/2017 08:39 PM, Jan Kiszka wrote:
> On 2017-11-23 14:18, Jorge Ramirez wrote:
>> On 11/23/2017 01:52 PM, Henning Schild wrote:
>>> Am Thu, 23 Nov 2017 12:42:08 +0100
>>> schrieb Philippe Gerum <rpm@xenomai.org>:
>>>
>>>> On 11/22/2017 09:27 PM, Jan Kiszka wrote:
>>>>> On 2017-11-22 16:32, Philippe Gerum wrote:
>>>>>> Hi Kendall,
>>>>>>
>>>>>> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>>>>>>> Hi Philippe,
>>>>>>>
>>>>>>> Is there an online bug tracking and feature request database?
>>>>>>> This would be a useful way to distribute work and to sync up
>>>>>>> contributors. I think the kernel uses Bugzilla, and Ubuntu has
>>>>>>> Launchpad. No doubt there are many others.
>>>>>>>
>>>>>>> I'd like to contribute in some way. I've been having a lot of fun
>>>>>>> as a Xenomai user.
>>>>>> We don't have that unfortunately. As suggested by several posters,
>>>>>> moving to a git-based, integrated development framework such as
>>>>>> gitlab or github would bring in that feature, and others we need
>>>>>> too (CI).
>>>>>>
>>>>>> I have no issue moving the project from the current git server at
>>>>>> xenomai.org to any of these environments.
>>>>>>    
>>>>> If it helps the community to grow, I would not refuse such a move.
>>>>> But I would like to raise some concerns about platforms like github
>>>>> or gitlab that we must be aware of:
>>>>>
>>>>> - lacking integration with email-based workflows (while kernel
>>>>>     development tends to be based on that...)
>>>>>
>>>>> - risk of decoupling communities when parts of the discussions
>>>>> happen on tickets or PRs and parts in mailing list threads
>>>>>
>>>>> Therefore, most projects I manage on github and in our internal
>>>>> gitlab have clear policies like "no emails, only tickets and PRs"
>>>>> or "no PRs, only patches on the mailing list". Even just using the
>>>>> issue tracker to keep some to-do list requires discipline to direct
>>>>> discussions consequently to a mailing list if that exists as well
>>>>> (and that usually does not work very well).
>>>>>
>>>>> IOW: we need to be clear in what we want a platform for - and what
>>>>> not.
>>>> Forking the original thread to get input from the list specifically
>>>> regarding the idea of moving GIT services from xenomai.org to a public
>>>> software development platform.
>>>>
>>>> As Jan mentioned, there is more than having GIT underneath, there are
>>>> deep implications on the workflow, and it really depends on what we'd
>>>> want from such platform. If you have any thought, recommendation,
>>>> experience with those platforms in your daily work, it would be great
>>>> to know your views.
>>> Jan is absolutely right here. Before moving to github (or something
>>> alike) you need to set groundrules for how to deal with PRs, issues and
>>> all the stuff that you suddenly gain.
>>>
>>> I think Xenomai could benefit from issue tracking and CI, not sure
>>> whether we need github for that.
>> issue tracking is not something that important IMO.
>> I dont believe this is extensively used by any projects but mainly distros.
>>
>>> The CI they offer is docker-based and
>>> we would likely want something more powerful. But i guess you could
>>> always use docker to remote control AWS or real hardware.
>> yes. there are a number of solutions that in fact do OTA and most of
>> them use Docker to control real hardware.
>> the industry seems to be going in that direction. I think Shippable
>> should server our purpose.
>>
>> for instance, check out this commit:
>> https://github.com/zephyrproject-rtos/zephyr/pull/5134
>>
>> and its shippable output
>> https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/7471/summary/console
>>
> Shippable looks interesting. We are working internally with gitlab-ci
> and for several public projects with Travis. But the free services are
> usually nothing for "serious" workload like kernel builds because they
> either lack powerful builders or have limits on the job length - or both
> which doesn't make it better. For Jailhouse, I worked around that in
> Travis by caching the required kernel build.
>
> Do you know what limits exist in shippable?

sorry no, I havent really looked into it; I mainly saw value in the way 
it integrates within the review process.

>
>>> github sucks at routing mails. My github account is shared between my
>>> work and personal stuff but i do not star/watch any work related
>>> projects because i do not want the notifications in my personal inbox.
>> I agree that it sucks but I dont see why this should be an issue.
>> Just dont rely on github emails (I personally tend to disable them, they
>> are extremely annoying).
>>
>> when I need to find out how any PR is progressing (every other day) I
>> just connect to github.
> It's a personal thing, but web UIs do not scale for me. I'm on way too
> many platforms, and all suck at least a little bit in certain ways. But
> then, when you then need to combine them to keep track, the problem
> becomes serious because email do not work for most of them. Again, a
> personal issue I just happen to share with many kernel hackers.

yes I know; it happens to me as well (ffmpeg, uboot, atf, kernel, AOSP, 
zephyr (first on gerrit, then on github)..they all have slightly 
different channels and processes (and in my case - I guess yours too- a 
myriad of development boards...switching between them all adds to the 
workload)

Having said that, I am questioning the validity of this reasoning, ie 
that we dont do something because it doesnt integrate with why a 
preferred individual way of working.
IMHO there has to be a valid, functional reason other than that.


>
> In the end, the platform we pick depends on the group of developers we
> want to attract. If the majority of our key contributors and maintainers
> become more productive for the project in a specific way, pick that one.

ah ok ,yes I agree with you: are you proposing that the process is 
succinctly defined by a core group of developers and the options then 
presented to the ML for consensus?

> But be careful with choices that cannot be changed again easily.

agree 100% - zephyr did move from gerrit to github and for a few weeks 
it was a PIA to find information.

>
>>> commitment to github etc. is likely to cause sort of a vendor lock-in.
>> ? what do you mean?
>>> I am sure the APIs can be used to extract some information, but will you
>>> get something that you can import into your own gitlab or track later
>>> on? As long as we only use git-hosting and CI from them that would not
>>> be too much of a problem.
>> yeah everything can be done (ie: at linaro we have lava-labs and
>> integrate our own CI loops with Jenkins and real hardware).
>> But I dont believe Xenomai has the dedicated resources for that.
>>
>> BTW at ELCE in Prague, Tgx's daughter presented a very interesting
>> approach [1] to accessing real hardware on CI (using libvirt). Very cool.
>> I think we should use it if in the end we decide to roll our own. But
>> IMO, Shippable should suffice.
>>
>> [1]
>> https://osseu17.sched.com/event/ByYA/continuous-integration-jenkins-libvirt-and-real-hardware-anna-maria-gleixner-manuel-traut-linutronix-gmbh
>>
> FWIW, collaboration projects like Automotive Grade Linux or our Civil
> Infrastructure Platform are significantly investing into LAVA now.

good to know!

>   And
> we also do this here internally. We are not yet at a point where we can
> easily spawn and/or scale out labs, but that time will come. It's an
> industry trend regarding collaborative testing right now, and I'm sure
> we will eventually be able to exploit it for Xenomai as well

100% agreed. everyone is doing this in the industry.

I also liked pretty much Kevin Hilman's kernel-ci [1]; unfortunately he 
doesnt accept patches not upstreamed in his board farm.
Maybe I could talk to Kevin/BayLibre about helping us set a Xenomai-CI 
similar to Kernel-CI?


[1] https://kernelci.org/

> .
>
> But let's focus on CI first. Then maybe easily retrievable test images
> for your manually operated test lab.
>
> Jan
>

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jorge Ramirez]

On 11/23/2017 09:35 PM, Lennart Sorensen wrote:
> On Thu, Nov 23, 2017 at 01:38:03PM +0100, Jorge Ramirez wrote:
>> In the past year alone I have been contributing to uboot (as board
>> maintainer), arm-trusted-firmware (board maintainer), ffmpeg (v4l2 support),
>> zephyr (multiple drivers), the linux kernel (some fixes), AOSP (fixes) and a
>> few others. So I have gained certain exposure to a number of workflows.
>>
>> with this in mind I think the Zephyr workflow would suit Xenomai nicely.
> I personally like the linux kernel workflow where everything is through
> a mailing list and patches are reviewed before they go in.  I am not
> sure that workflow would work for xenomai, but I do like it.

we all like the kernel workflow and the release process. In fact, in 
seems to scale ad-infinitum.
however we dont have this need AFAIK.

>
>> It spins around Github and integrates with Shippable - this means that on
>> each pull request, we can trigger a full rebuild and run sanity and maybe
>> even performance tests before any code review can begin; the subsystem
>> maintainer/s then can review the pull request adding comments on the code as
>> it moves along.
> I am not sure build tests are that useful given the number of different
> platforms the code runs on.  Which one do you build test for?

all the default configs in the tree. 10, 20, 200, whatever.

>
>> Xenomai also lacks an IRC channel which makes things way too quiet for a
>> small size community (in the case of ffmpeg for instance IRC is where most
>> if not all the discussions happen). IRC is - and should be for Xenomai- a
>> good place to ask for help and direction. So I vote for having one.
> IRC is useless when the community is small and spread across timezones.
> At least with the mailing list people will see the question and can
> answer it when it hits their timezone.  IRC isn't helpful when no one
> is there to read your question when you write it.  And good luck trying
> to convey anything complex in an IRC conversation.

complex stuff gets discussed in ML.
simple stuff, information sharing, light details, simple blocks, pings, 
that is what IRC is for.

tends to works well;
maybe try joining #ffmpeg,#kodi, #u-boot, ##linux-msm, etc and have a 
peak if you are not used to IRC.


> Want to try sending
> source code patches through IRC for discussion?

this would be ridiculous if it was for an upstream complex review.

if it is for a quick discussion with someone in the channel, sure, you 
can send a patch - as a code snippet - using paste services [1] obviously.
This is very common these days.

>
> I check my email daily.  I don't check random websites daily to check
> the forums for project x, y and z each with a different interface.
> Too much work.

what do you mean about random websites? you lost me there.

>
>> To sum up, given the low rate of patches that Xenomai handles and given the
>> need push back on performance degradation I strongly believe that the
>> Zephyr's workflow would work for us. The way performance ramifications are
>> maintained today is pretty much living in Philippe's and possibly Jan's
>> head: I think we should move from intuition to explicit measurable data when
>> merging PRs (ie, establishing a multi-board CI loop)


[1] https://hastebin.com/

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Jorge Ramirez]

On 11/24/2017 11:46 AM, Stéphane Ancelot wrote:
> Hi guys,
>
> Here at Numalliance, as xenomai development contributors and users, we 
> can  give only a quick reply to some points at the moment :
>
> Regarding irc/mailing lists , we would prefer tools like  Discord, 
> that is a modern,very  good collaborative and interactive tool to 
> discuss subjects.Using either text or voice channels.
> You will not attract young people generation with IRC .

IMO those recent graduates will be attracted by the technology itself - 
they will be able to do things - and create businesses - that others 
can't do without Xenomai/RT support.

and besides, should first agree on having a mailing list and a channel 
and then decide on the best channel?
Even though I agree with you (I want a channel :) ) It seems most of the 
folks in the ML are mostly interested in off-line discussions anyway.

>
> an issue tracker would be mandatory in order to :
> * identify problems and permit resolution to anyone wanting  to 
> contribute and solve it
> * link issues with the software repository and resolution (back and 
> forth) , (we are using redmine )
> * history tracking

I still dont think an issue tracker is necessary (but my opinion is 
obviously as good as any).
I would much rather have a kanban board with a 10 mile view of the 
project. That is easy to maintain.

>
> I know many opensource projects are using stackoverflow  as main 
> website support  .
> It permits knowledge sharing.
> Questions/Replies  are often reviewed by other people and thus 
> filtered if questions need clarifying or duplicated issues ...

I think that is what the ML is for. Xenomai doesnt have the resources 
(AFAIK) to maintain something like we have in 96boards [1]

>
> The xenomai API is not enough documented in order to permit new 
> developer's entry.
> Targetting and permitting students to contribute could be a good benefit.

absolutely.

>
>
> Unit tests cases seem mandatory .

agree


[1] https://discuss.96boards.org/

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jorge Ramirez]

On 11/26/2017 06:49 PM, Jorge Ramirez wrote:
> On 11/23/2017 09:35 PM, Lennart Sorensen wrote:
>> On Thu, Nov 23, 2017 at 01:38:03PM +0100, Jorge Ramirez wrote:
>>> In the past year alone I have been contributing to uboot (as board
>>> maintainer), arm-trusted-firmware (board maintainer), ffmpeg (v4l2 
>>> support),
>>> zephyr (multiple drivers), the linux kernel (some fixes), AOSP 
>>> (fixes) and a
>>> few others. So I have gained certain exposure to a number of workflows.
>>>
>>> with this in mind I think the Zephyr workflow would suit Xenomai 
>>> nicely.
>> I personally like the linux kernel workflow where everything is through
>> a mailing list and patches are reviewed before they go in.  I am not
>> sure that workflow would work for xenomai, but I do like it.
>
> we all like the kernel workflow and the release process. In fact, in 
> seems to scale ad-infinitum.
> however we dont have this need AFAIK.
>
>>
>>> It spins around Github and integrates with Shippable - this means 
>>> that on
>>> each pull request, we can trigger a full rebuild and run sanity and 
>>> maybe
>>> even performance tests before any code review can begin; the subsystem
>>> maintainer/s then can review the pull request adding comments on the 
>>> code as
>>> it moves along.
>> I am not sure build tests are that useful given the number of different
>> platforms the code runs on.  Which one do you build test for?
>
> all the default configs in the tree. 10, 20, 200, whatever.
>
>>
>>> Xenomai also lacks an IRC channel which makes things way too quiet 
>>> for a
>>> small size community (in the case of ffmpeg for instance IRC is 
>>> where most
>>> if not all the discussions happen). IRC is - and should be for 
>>> Xenomai- a
>>> good place to ask for help and direction. So I vote for having one.
>> IRC is useless when the community is small and spread across timezones.
>> At least with the mailing list people will see the question and can
>> answer it when it hits their timezone.  IRC isn't helpful when no one
>> is there to read your question when you write it.  And good luck trying
>> to convey anything complex in an IRC conversation.
>
> complex stuff gets discussed in ML.
> simple stuff, information sharing, light details, simple blocks, 
> pings, that is what IRC is for.
>
> tends to works well;
> maybe try joining #ffmpeg,#kodi, #u-boot, ##linux-msm, etc and have a 
> peak if you are not used to IRC.
>
>
>> Want to try sending
>> source code patches through IRC for discussion?
>
> this would be ridiculous if it was for an upstream complex review.
>
> if it is for a quick discussion with someone in the channel, sure, you 
> can send a patch - as a code snippet - using paste services [1] 
> obviously.
> This is very common these days.

as a matter of fact- and without going in detail, I wasnt following this 
discussion- Peter Zijlstra shared this [1] today in #linux-rt with some 
other guy and tglx

[1] http://paste.debian.net/997825/

anyway, my point is, this is an efficient way of discussing quick 
issues/changes between peers.

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Lennart Sorensen]

On Sun, Nov 26, 2017 at 06:49:12PM +0100, Jorge Ramirez wrote:
> we all like the kernel workflow and the release process. In fact, in seems
> to scale ad-infinitum.
> however we dont have this need AFAIK.
> 
> all the default configs in the tree. 10, 20, 200, whatever.
> 
> complex stuff gets discussed in ML.
> simple stuff, information sharing, light details, simple blocks, pings, that
> is what IRC is for.
> 
> tends to works well;
> maybe try joining #ffmpeg,#kodi, #u-boot, ##linux-msm, etc and have a peak
> if you are not used to IRC.

I used to spend a lot of time on IRC.  Way too much time helping people
with linux issues of various kinds.  Doing things live was way too time
consuming, so I decided to ban myself from IRC.  I think it has been
almost 10 years now that I have avoided IRC.

> this would be ridiculous if it was for an upstream complex review.
> 
> if it is for a quick discussion with someone in the channel, sure, you can
> send a patch - as a code snippet - using paste services [1] obviously.
> This is very common these days.

The nice thing with the mailing list ist that everyone that is interested
gets to see it.  With IRC only those that were around on IRC at the time
get to see it.

> what do you mean about random websites? you lost me there.

Some people think webforums are better for discussions than mailing lists.
But that is yet another place you have to think to go read.

-- 
Len Sorensen

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Wolfgang Denk]

Dear Philippe,

In message <2f850a60-3756-f06d-82c6-ccf6eeb58aa3@xenomai.org> you wrote:
>
> As Jan mentioned, there is more than having GIT underneath, there are
> deep implications on the workflow, and it really depends on what we'd
> want from such platform. If you have any thought, recommendation,
> experience with those platforms in your daily work, it would be great to
> know your views.

Full agreement.

What I can offer here an now is this:

1) DENX can run the Xenomai mailing list.

   We already run some other lists, the U-Boot mailing list with
   currently 2877 members being the most important. Adding another
   list is just a few clicks aways.

   [OK, it takes abit more work to transfer the old mail archives,
   but all this is pretty much straightforward.]

2) DENX can host one ore more repositories for Xenomai on our gitlab
   server (gitlab.denx.de).  We're planning for an upgrade anyway,
   and compared to other stuff we have there Xenomay is just a tiny
   addition.

Both services can be provided immediately.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The bad reputation UNIX has gotten is totally undeserved, laid on by
people who don't understand, who have not gotten in there  and  tried
anything."          -- Jim Joyce, owner of Jim Joyce's UNIX Bookstore

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Wolfgang Denk]

Dear Lennart,

In message <20171123203533.h2qfccbyxdavhpej@csclub.uwaterloo.ca> you wrote:
>
> I personally like the linux kernel workflow where everything is through
> a mailing list and patches are reviewed before they go in.  I am not
> sure that workflow would work for xenomai, but I do like it.

I share the same experience and feelings from working with U-Boot
for 18 years.

But then, it all depends on a) people who submit patches and b)
people who review these and c) maintainers who pull this stuff in.

It would be trivial to set up the neede dinfrastructure to process
such patches at patchowrk, for example.  All these technical issues
can be solved easily.

It does not solve the consumer-only mindset that dominates the list
of subscribers of the Xenomai list.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
On our campus the UNIX system has proved to be not only an  effective
software tool, but an agent of technical and social change within the
University.                          - John Lions (U. of Toronto (?))

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Philippe Gerum]

Hello Wolfgang,

On 11/27/2017 09:41 PM, Wolfgang Denk wrote:
> Dear Philippe,
> 
> In message <2f850a60-3756-f06d-82c6-ccf6eeb58aa3@xenomai.org> you wrote:
>>
>> As Jan mentioned, there is more than having GIT underneath, there are
>> deep implications on the workflow, and it really depends on what we'd
>> want from such platform. If you have any thought, recommendation,
>> experience with those platforms in your daily work, it would be great to
>> know your views.
> 
> Full agreement.
> 
> What I can offer here an now is this:
> 
> 1) DENX can run the Xenomai mailing list.
> 
>    We already run some other lists, the U-Boot mailing list with
>    currently 2877 members being the most important. Adding another
>    list is just a few clicks aways.
> 
>    [OK, it takes abit more work to transfer the old mail archives,
>    but all this is pretty much straightforward.]
> 
> 2) DENX can host one ore more repositories for Xenomai on our gitlab
>    server (gitlab.denx.de).  We're planning for an upgrade anyway,
>    and compared to other stuff we have there Xenomay is just a tiny
>    addition.
> 
> Both services can be provided immediately.
> 
> 

Thank you for your kind proposal. Looking at the related discussion
earlier on this list, it seems that there is a consensus about gitlab
being one of the few appropriate options for the project, provided we
prevent cross-talk between the issue tracker and the mailing list,
choosing the latter exclusively.

I believe that such solution would be in the best interest of the user
base, providing for issue tracking and CI in the same move. Since Gitlab
also provides an integrated wiki, we could use it to publish the
existing documentation currently on http://xenomai.org which is entirely
composed of static contents.

This would not preclude from using additional services in the future
(IRC etc) hosted elsewhere, but having the core infrastructure at a
trusted place like Denx is the right move.

I'll get in touch with your team for carrying out this migration
gradually from my server to denx.de.

Thanks again.

-- 
Philippe.

Re: [Xenomai] [RFC] Service hosting for Xenomai

[Henning Schild]

Am Mon, 27 Nov 2017 22:44:03 +0100
schrieb Philippe Gerum <rpm@xenomai.org>:

> Hello Wolfgang,
> 
> On 11/27/2017 09:41 PM, Wolfgang Denk wrote:
> > Dear Philippe,
> > 
> > In message <2f850a60-3756-f06d-82c6-ccf6eeb58aa3@xenomai.org> you
> > wrote:  
> >>
> >> As Jan mentioned, there is more than having GIT underneath, there
> >> are deep implications on the workflow, and it really depends on
> >> what we'd want from such platform. If you have any thought,
> >> recommendation, experience with those platforms in your daily
> >> work, it would be great to know your views.  
> > 
> > Full agreement.
> > 
> > What I can offer here an now is this:
> > 
> > 1) DENX can run the Xenomai mailing list.
> > 
> >    We already run some other lists, the U-Boot mailing list with
> >    currently 2877 members being the most important. Adding another
> >    list is just a few clicks aways.
> > 
> >    [OK, it takes abit more work to transfer the old mail archives,
> >    but all this is pretty much straightforward.]
> > 
> > 2) DENX can host one ore more repositories for Xenomai on our gitlab
> >    server (gitlab.denx.de).  We're planning for an upgrade anyway,
> >    and compared to other stuff we have there Xenomay is just a tiny
> >    addition.
> > 
> > Both services can be provided immediately.
> > 
> >   
> 
> Thank you for your kind proposal. Looking at the related discussion
> earlier on this list, it seems that there is a consensus about gitlab
> being one of the few appropriate options for the project, provided we
> prevent cross-talk between the issue tracker and the mailing list,
> choosing the latter exclusively.
> 
> I believe that such solution would be in the best interest of the user
> base, providing for issue tracking and CI in the same move. Since
> Gitlab also provides an integrated wiki, we could use it to publish
> the existing documentation currently on http://xenomai.org which is
> entirely composed of static contents.
> 
> This would not preclude from using additional services in the future
> (IRC etc) hosted elsewhere, but having the core infrastructure at a
> trusted place like Denx is the right move.

For the mailinglist we should keep the domain "xenomai.org" and the
address. And it would be nice to move to a server that can handle
subscribers/posters that are in a DMARC-enabled domain.

Henning

> I'll get in touch with your team for carrying out this migration
> gradually from my server to denx.de.
> 
> Thanks again.
> 

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane Ancelot]

Hi,

This may be offtopic regarding xenomai itself.

But, I am a member of the kde community, which is very active.Recently, 
they made some proposals to improve onboarding of new contributors.

I think there are some very good ideas that can apply here, here is the 
link.

https://phabricator.kde.org/T7116

Regards,

S.Ancelot


Le 21/11/2017 à 18:11, Philippe Gerum a écrit :
> As the GIT commit history shows, there has been no sustained effort in
> maintaining several of the Xenomai I/O frameworks for several months
> (e.g. RTnet, analogy), even years in some cases, despite obvious bugs
> are still haunting the code base according to the mailing list. The
> situation has reached a point where I see no alternative to dropping
> them if the situation does not improve, because there is absolutely no
> point in this project shipping bit rot software that won't ever be fixed.
>
> Unfortunately, this is only the tip of the iceberg. Let's face it, since
> Gilles passed away last year, I have not been scaling to the Xenomai
> maintenance, development and documentation tasks, with the requirement
> of running my business in parallel.
>
> The solution to this serious problem is fitting the project to the
> available resources by narrowing its goal, or conversely, by growing the
> pool of contributors.
>
> In addition, we can rework the most tricky part of the implementation to
> make it simpler to maintain, better documented, drastically lowering the
> barrier on entry for new contributors, which is what I've been working
> on for a year with the 4th generation of the interrupt pipeline.
> Progress on this front has been significant already, but once again
> limited by the time I have been able to devote to this development so far.
>
> For the past 16 years, this project has lived on various types of
> contributions from only a few committed people and companies. At this
> chance, let's mention that people who have been deploying Xenomai in
> industrial applications owe a lot to Wolfgang Denk from Denx
> Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported
> the project in crucial ways directly or indirectly over the years, and
> still do.
>
> Xenomai as a dual kernel technology showcase has been quietly delivering
> on the promise of real-time Linux for more than a decade now, with
> marketing tools limited to showing decent code quality, good and
> reliable performance figures. As a result, to my current knowledge,
> Xenomai is present in a broad range of applications and systems:
> magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> communication equipment, autonomous vehicles, control & automation
> systems in various plants.
>
> On the sad side of the story, this project has virtually become a
> one-man show the day Gilles - my long-time friend and hacking soul mate
> - left us. That show is too big for me to run it alone, which entails
> maintaining:
>
> - the interrupt pipeline for 7 CPU architectures
> - the Cobalt co-kernel
> - 4 APIs, plus the "copperplate" mediating layer
> - several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI, GPIO
> - the documentation (which is currently unfriendly to newcomers, and
> stalled two years ago or so)
> - the website
> - the testing and release processes
>
> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.
>
> Thanks,
>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane Ancelot]

Le 25/11/2017 à 21:32, Philippe Gerum a écrit :
> On 11/24/2017 11:46 AM, Stéphane Ancelot wrote:
>> The xenomai API is not enough documented in order to permit new
>> developer's entry.
> Can you elaborate on what could be done to improve the documentation,
> according to your own experience with it?
It is difficult to understand which version / release to use ?
Difference between what is stable / unstable is not really clear.
I lost many times using some versions, then trying another one, because 
of some bugs .....
And finally at a moment, in real life, altough you may know  there are 
some problems in the implementation you are using, you must stick to a 
version, you have delivery date....


When you read the docs , you are in front of "new" terms : cobalt / 
mercury, alchemy ... that's a bit confusing mixing everything in the 
right order. Do I need it, or not ?
what is the right guideline ?
You have to brainstorm yourself to understand what is cobalt, how it is 
working, the added value .
What will I use ?

next , there are many API (alchemy, cobalt, psos, vxworks ,posix ...), 
luckily if it works, you change your code and mix api !!!
Many api imply more complexity and  maintenance, are all these API 
really mandatory ?????


>> Targetting and permitting students to contribute could be a good benefit.
>>
> How would you do that?
>
>> Unit tests cases seem mandatory .
>>
> There are (testsuite/smokey), but clearly not enough of them though.
>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane Ancelot]

Le 01/12/2017 à 16:09, Stéphane Ancelot a écrit :
>
>
> Le 25/11/2017 à 21:32, Philippe Gerum a écrit :
>> On 11/24/2017 11:46 AM, Stéphane Ancelot wrote:
>>> The xenomai API is not enough documented in order to permit new
>>> developer's entry.
>> Can you elaborate on what could be done to improve the documentation,
>> according to your own experience with it?
> It is difficult to understand which version / release to use ?
> Difference between what is stable / unstable is not really clear.
> I lost many times using some versions, then trying another one, 
> because of some bugs .....
> And finally at a moment, in real life, altough you may know  there are 
> some problems in the implementation you are using, you must stick to a 
> version, you have delivery date....
>
>
> When you read the docs , you are in front of "new" terms : cobalt / 
> mercury, alchemy ... that's a bit confusing mixing everything in the 
> right order. Do I need it, or not ?
> what is the right guideline ?
> You have to brainstorm yourself to understand what is cobalt, how it 
> is working, the added value .
> What will I use ?
>
EDIT :
> next , there are many API (alchemy, cobalt, psos, vxworks ,posix ...), 
> you may face some bugs, so, you try it in another API, luckily if it 
> works, you change your code and mix api !!!
> Many api imply more complexity and  maintenance, are all these API 
> really mandatory ?????
>
>
>>> Targetting and permitting students to contribute could be a good 
>>> benefit.
>>>
>> How would you do that?
>>
>>> Unit tests cases seem mandatory .
>>>
>> There are (testsuite/smokey), but clearly not enough of them though.
>>
>
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Steven Seeger]

> Hi Steven,
> 
> I have remote access to many ppc boards and could help here. This said
> 85xx, 40x and 44x already cover much of the ppc32 scope running Xenomai
> - maybe adding mpc52xx would be good, I have one here. I don't see much
> traction these days for Xenomai over ppc64, so I'm not even sure whether
> this port is still relevant.

I have never used ppc64 so I would take some time coming up to speed with it 
(and would need access to a board.) I am sure you can tell from all our 
private emails over the last couple years that I wouldn't have a problem with 
ppc32. 

I am unsure how remote access to boards works especially at this level of 
work. Is there some way to power on and off if needed or do they depend on a 
watchdog? We can discuss this offline.

Steven

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

Hi Steven,

On 11/22/2017 05:49 PM, Steven Seeger wrote:
> Philippe, as we have previously discussed I am willing to take over the PPC i-
> pipe maintenance on my personal time if it will help.

Thanks, that would be great.

 My only issue is right
> now the only PPC board I have in my posseession is an 8548-based board. I 
> might be able to borrow some 405 and 440-based boards from work if needed. Of 
> course, we can always depend on the grateful Xenomai users for test and 
> feedback. :)
>

I have remote access to many ppc boards and could help here. This said
85xx, 40x and 44x already cover much of the ppc32 scope running Xenomai
- maybe adding mpc52xx would be good, I have one here. I don't see much
traction these days for Xenomai over ppc64, so I'm not even sure whether
this port is still relevant.

> I am not sure my group is going to pursue RTNET otherwise I would have been 
> happy to help there. I think negotations are still open on that one, though.
> 
> If we ever get around to releasing my microblaze i-pipe patch then I am happy 
> to maintain that as well. :) Feel free to email me privately if you want to 
> discuss.

Ok.

> 
> I really miss Gilles and maybe I can help carry on his memory in some small 
> way. Hopefully he is in heaven where there are no geode CPUs to chase FPU bugs 
> on :)


-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/22/2017 11:06 AM, Norbert Lange wrote:
> Hi,
> 
> not really happy to hear that, but this was already my impression.
> There is alot of knowledge of kernel, hardware and bootloader
> knowledge necessary to be able to maintain the ipipe patch, as
> newcomer to most of these I am just helpless. Unless someone is
> dedicated to that,
> there is not chance to keep up.
> 
> What you could do is to automate as much as possible, saving some of
> the regular grinding work.
> The way realtime is used with minimal configurations, FTB errors will
> show up late,
> and changes in kernel APIs are only carried over in actively used drivers.
> 
> ie.
> -   automated builds with several kernel configs

Agreed. We used to have that, until last year. We need this back.

> -   potential some tests under qemu with the above.
> 
> Buildroot does something similar, and this is very low maintenance
> cost once its setup,
> could automatically report issues or non-working config-switches.

Do you mean buildroot-CI?

> Nowadays you can let providers like Gitlab take care of keeping the
> servers running,
> as I understand it you have no limits to build-time unless the project
> is private.
> You get some good issue tracking on top of it, patches can be
> automatically checked in form of merge-requests.
> (In the unlikely case they go bust or get unfriendly, you can still
> tun an older Gitlab version on your own server)
> 
> 
> I really don`t see the advantage in separating the subprojects,
> its already complicated enough to piece everything together,
> and with automated builds you could atleast catch build-errors or fails-to-boot.
> I take unmaintained, but buildable code in-tree over unmaintained code
> in a separate project everyday.

Moving to Gitlab is definitely an option on the table.

> 
> Publicity
> 
> Dont know how to takle this, but its very easy to get a full IDE and
> start programming some embedded CPUs.
> Commercial OSes have a huge advantage there, cause it doesnt take much
> to get example code running (youre only going to hit walls as your
> problems get bigger than their ecosystem). First impressions count,
> and being able to debug through code gets you firsthand knowledge
> faster than any other approach.
> 
> In that respect some known-to-work hardware with known-to-work
> dual-kernel with a pre-setup dev environment would go a long way to
> ease the first steps and might gather some new interested users.
> Some cheap, high-volume, jtag-debugable SBC would do.
> 
> Otherwise theres some architecture-, bios- and ever changing
> kernel-magic involved just to get a plain system running.

Agreed, the idea of, e.g. a live image booting Xenomai to lower the
barrier on entry is a nice way to attract new users. This said, the
discussion I would like to see first is about fixing the existing issues
in the development and maintenance processes so that current users have
their investment in Xenomai kept safe.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Steven Seeger]

Philippe, as we have previously discussed I am willing to take over the PPC i-
pipe maintenance on my personal time if it will help. My only issue is right 
now the only PPC board I have in my posseession is an 8548-based board. I 
might be able to borrow some 405 and 440-based boards from work if needed. Of 
course, we can always depend on the grateful Xenomai users for test and 
feedback. :)

I am not sure my group is going to pursue RTNET otherwise I would have been 
happy to help there. I think negotations are still open on that one, though.

If we ever get around to releasing my microblaze i-pipe patch then I am happy 
to maintain that as well. :) Feel free to email me privately if you want to 
discuss.

I really miss Gilles and maybe I can help carry on his memory in some small 
way. Hopefully he is in heaven where there are no geode CPUs to chase FPU bugs 
on :)

Steven

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Norbert Lange]

Hi,

not really happy to hear that, but this was already my impression.
There is alot of knowledge of kernel, hardware and bootloader
knowledge necessary to be able to maintain the ipipe patch, as
newcomer to most of these I am just helpless. Unless someone is
dedicated to that,
there is not chance to keep up.

What you could do is to automate as much as possible, saving some of
the regular grinding work.
The way realtime is used with minimal configurations, FTB errors will
show up late,
and changes in kernel APIs are only carried over in actively used drivers.

ie.
-   automated builds with several kernel configs
-   potential some tests under qemu with the above.

Buildroot does something similar, and this is very low maintenance
cost once its setup,
could automatically report issues or non-working config-switches.
Nowadays you can let providers like Gitlab take care of keeping the
servers running,
as I understand it you have no limits to build-time unless the project
is private.
You get some good issue tracking on top of it, patches can be
automatically checked in form of merge-requests.
(In the unlikely case they go bust or get unfriendly, you can still
tun an older Gitlab version on your own server)


I really don`t see the advantage in separating the subprojects,
its already complicated enough to piece everything together,
and with automated builds you could atleast catch build-errors or fails-to-boot.
I take unmaintained, but buildable code in-tree over unmaintained code
in a separate project everyday.

Publicity

Dont know how to takle this, but its very easy to get a full IDE and
start programming some embedded CPUs.
Commercial OSes have a huge advantage there, cause it doesnt take much
to get example code running (youre only going to hit walls as your
problems get bigger than their ecosystem). First impressions count,
and being able to debug through code gets you firsthand knowledge
faster than any other approach.

In that respect some known-to-work hardware with known-to-work
dual-kernel with a pre-setup dev environment would go a long way to
ease the first steps and might gather some new interested users.
Some cheap, high-volume, jtag-debugable SBC would do.

Otherwise theres some architecture-, bios- and ever changing
kernel-magic involved just to get a plain system running.