I thought the meeting was great thanks to everyone that set it up.  I
think it really got some things out in the open.  Moving forward what
items should we tackle first?  I also have these two how to articles
that I made a while ago.  I need to clean up the information in it
since I've learned more since and they can be improved.  If anyone is
looking at tackling the tutorials we talked about during the meeting
and would like to use them as a reference please feel free.  They are
geared towards Zynq but they can be generalized.  Once I get these
raspberry pi images to a point where I can share, I'd be happy to work
with someone on gearing some of the getting started material towards
raspberry pi.

https://embeddedgreg.com/2017/07/16/getting-started-with-xenomai-3-on-zynq/

https://embeddedgreg.com/2017/08/08/hello-xeno-world/

-Greg

On Thu, Feb 8, 2018 at 8:51 AM, Henning Schild
<henning.sch...@siemens.com> wrote:
> Hi,
>
> on 02/02/18 we had an open community meeting in Brussels to discuss
> topics around Xenomai. Both the recent development as well as plans for
> the future.
>
> We at Siemens work closely together with Philippe Gerum. We first
> considered inviting him to our office in Munich and have an internal
> meeting. But i am happy we went for the open meeting instead. The crowd
> was not too big and some attendees where mostly silent, i would still
> call it a success. For me personally it was nice to meet in person,
> after contributing to Xenomai for a few years now.
> Let us see whether we can make that a more regular event and motivate
> even more people to show up and speak about their usage of Xenomai in
> their projects or even products.
>
> Henning
>
> --------
>
> Attendees:
> ----------
> local:
>  Philippe Gerum, Karim Yaghmour, Jan Leupold, Sebastian Smolorz, Jeroen
>  Van den Keybus,  Niels Wellens, Jan Kiszka, Henning Schild
> remote:
>  Greg Gallagher, Dmitriy Cherkasov
>
> Ipipe:
> ------
> - it was decided that the following arches will not be supported
>   anymore:
>   - blackfin, ppc64, arm32 < v7
> - the remaining ones will be maintained by these people
>  - Steven Seeger ppc32
>  - Dimitri Cherkasov arm64
>  - Philippe Gerum arm32 >= v7
>  - Jan Kiszka i386/x86_64
> - Philippe described the current state of the pipeline patches
>  - the maintainability of these patches was identified as a critical
>    issue of the project
>  - hard to rebase, understand etc.
> - new approach for the patches discussed
>  - split "the patch" into a clear series of patches, with meaningful
>    commit messages
>  - and improve that split over time
>  - that should mitigate the mentioned problems, increase quality and
>    ease maintenance
>  - authership of contributions should be kept
> - supported kernel versions
>  - we will aim to provide ipipe-patches for the respective latest LTS
>  - patch series will be rebased onto .0 release
>  - in rebase fold/squash or split patches to keep it a clear series
>  - it is not fully clear whether rebase or merge workflows will be used
>    within one release (i.e. from 4.4.0 to 4.4.71)
>  - only _one_ LTS kernel will be officially supported at a time
>  - older LTS branches can be maintained if anyone signs up for doing
>    that (Siemens is likely to keep working on 4.4 for a while)
>  - maintainers of such branches will have to "poll" the latest branch
>    to find out about fixes that might require backporting
> - upstreaming of Ipipe
>  - the current patchset can not be used for upstreaming into the Linux
>    kernel
>  - the new split patchqueue could have some potential for getting tiny
>    bits merged
>  - for the real merge, Philippe has version 4 of the pipeline in the
>    making
>   - that could "come close" but is still in the making (with little
>     time to work on it)
>   - we will need a "user" of that when we propose it upstream
>
> Workflows/Releases:
> -------------------
> - upcoming release of ipipe 4.14
>  - x86 still has FPU issues, the rest is done
> - upcoming xenomai release 3.0.7
>  - contains rtnet-fixes, x86 build fixes and more
>  - still waiting for ipipe-4.14 but could be released without that
> - upcoming xenomai release 3.1
>  - introduce arm64, see git
>  - waiting for ipipe-4.14
>
> - there will be no release plan or schedule
> - users should learn to use git and forget about release tags
>
> Infrastructure:
> --------------
> - xenomai and ipipe will move to gitlab of denx (should be mostly
>   transparent for users)
> - mailinglist moves to denx (again, should be transparent)
> - open questions:
>  Will issues, pull-request and wikis from gitlab be open?
>  Will the website move into gitlab?
>
> Roles:
> ------
> - Ipipe arch maintainers (see above)
> - Philippe Gerum: Ipipe Integrator
> - Philippe wants to hand over most of his current duties until 09/18
>
> Roles/Tasks we need volunteer for:
>  - release manager
>  - public relations
>   - gather/collect information from the "inside"
>    - who is using xenomai, for what, who is working on what, which
>      arches are of interest, where does the community see issues
>   - outside
>    - talks on conferences
>    - publish whitepapers on your products (so the project can reference
>      you as a user)
>   - annual conference ??
>   - PR is a role that everyone should contribute to!
>   - collect users overview, maybe start surveys
>   - usage stats could be extracted from our website, downloads,
>     mailinglists
>    - for now we do not look at that and try to not be nosy
>    - if we use it, we will make these stats available
>    - usage stats could be very useful for users as well
>     - get an idea how popular Xenomai is
>     - where in the world
>     - which versions especially
>  - improve documentation
>   - write a recent "hello world" tutorial
>   - describe the "dual-kernel-approach" from high-level to help
>     newcomers
>   - such tasks should be taken over by people that do not actually know
>     too much about xenomai, to cover the real painpoints that devs
>     would not run into
>  - testing responsible
>
> Drivers:
> --------
> - drivers are the biggest issue in the "xenomai" side of the project
>   - bit rot, often do not even compile and seem broken since years
> - discard or keep them -> probably start discarding them bit by bit
> - some serve as useful examples/templates but others are in such a bad
>   state that they make very bad examples
> - "analogy" is basically unmaintained since 7 years
>  - how many users are actually interested in that? from the attendees
>    we had a 0.5/10
>  - mostly untested and barely made to work on 3.x
>
> Documentation:
> --------------
> - we assume the Ipipe-side will get solved with the transformation of
>   "the patch" to the perfectly understandable series ;)
> - overall there is high quality documentation of almost all aspects of
>   Xenomai
> - it is not be structured in a way that is easy to find/consume
> - hence the need for restructuring when we move the website to the new
>   hoster
> - and the need to write tutorial that walk newcomers through the
>   technical details and introduce docs at appropriate places
>
> - it would be nice if more users spoke openly about using xenomai
>   - the typical industry consume-only way is a problem for the project
>   - write a white paper and get in touch so we can publish a link on
>     the website
>   - or show up with your real domain on the mailinglist
>   - why do you use xenomai, why not i.e. Preempt-RT
>    - if we all know about each other it is much easier to stand against
>      "the troll" or your manager that thinks he can just buy such a
>      thing
>
> Testing:
> --------
> - with the new hoster we will have gitlab-ci to control or run all
>   sorts of tests
> - at the end we would like to have all that in CI:
>   - compile tests for all arches and multiple configs
>   - full OS image generation for testing on reference boards
>   - functional testing "smokey"
>   - performance testing ("latency", "switch-test" etc. combined with
>     stress, dd, ...)
> - we will have to divide and conquer and start with the low-hanging
>   fruits like compile-only
> - all testing infrastructure should be open, ideally contributers
>   should be able to use it as well, or at least see the reports
> - Gilles used to run a CI that could do a lot of the above
>  - but that was pretty custom and would be hard to use/maintain without
>    Gilles ... given the code can still be found

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

Reply via email to