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