Hello everyone, Here is the link to my GSoC proposal. Will love if you leave comments on ways I could make it better or any corrections (Especially the *Proposesd Schedule* section so that I will be sure about my project deliverables when inputting them). https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing I will also love to know about any future improvements to this project.
Cheers, Ida. On Wed, Apr 7, 2021 at 5:27 PM Gedare Bloom <ged...@rtems.org> wrote: > On Wed, Apr 7, 2021 at 10:11 AM Ida Delphine <idad...@gmail.com> wrote: > > > > Hello, > > > > In case I succeed with this project will I be required to do some > documentation on how it works? > > > Yes, in general we expect students to produce documentation while they > work on also creating code. > > I think the direction we're heading right now is toward using > clang-format, perhaps with an update to a common coding style. In this > case, we solve our problem by policy rather than technical solution, > and your work should focus on tool integration and automation without > concern about the coding style itself. > > > > > On Wed, Apr 7, 2021 at 9:51 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> > >> On 07/04/2021 09:03, Chris Johns wrote: > >> > >> > Would it be pragmatic to review these cases and change the standard? > >> > >> I sent a patch to review the format changes done by clang-format > recently: > >> > >> https://lists.rtems.org/pipermail/devel/2021-April/066311.html > >> > >> It doesn't look that bad from my point of view. Fixing the alignment > >> issue would make it even better: > >> > >> https://reviews.llvm.org/D27651 > >> > >> > > >> > I understand the long history but as you point out we either invest > in the tools > >> > to support the format, we change what we have or we manage it > manually. > >> I would prefer to change the style and use a widely used formatting > >> tool. I think we spend to much time on the coding style in reviews. This > >> is quite bad since we are all busy with all sorts of things and our time > >> is better spent on more important tasks. A consistently formatted source > >> code is very important, but enforcing this style manually is a waste of > >> time. > >> > >> -- > >> embedded brains GmbH > >> Herr Sebastian HUBER > >> Dornierstr. 4 > >> 82178 Puchheim > >> Germany > >> email: sebastian.hu...@embedded-brains.de > >> phone: +49-89-18 94 741 - 16 > >> fax: +49-89-18 94 741 - 08 > >> > >> Registergericht: Amtsgericht München > >> Registernummer: HRB 157899 > >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > >> Unsere Datenschutzerklärung finden Sie hier: > >> https://embedded-brains.de/datenschutzerklaerung/ > >> > >> _______________________________________________ > >> devel mailing list > >> devel@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
