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
