I've been lurking on this list for a while, and looking forward to seeing some of you face-to-face. I'm a Portland native, so feel free to use me as a resource when planning your visit.
> -----Original Message----- > From: Xenomai [mailto:xenomai-boun...@xenomai.org] On Behalf Of Greg > Gallagher > Sent: Friday, January 26, 2018 11:02 AM > To: Jan Kiszka <jan.kis...@siemens.com> > Cc: Steven Seeger <steven.see...@nasa.gov>; Xenomai@xenomai.org > Subject: Re: [Xenomai] [RFC] FOSDEM meeting agenda > > 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 _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
