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
