code reformatting was Re: Regarding gsoc project 3860

Christian MAUDERER christian.mauderer at
Tue Mar 16 13:12:24 UTC 2021

Am 15.03.21 um 23:05 schrieb Gedare Bloom:
> On Mon, Mar 15, 2021 at 6:44 AM Joel Sherrill <joel at> wrote:
>> On Mon, Mar 15, 2021 at 4:20 AM Hesham Almatary <hesham.almatary at> wrote:
>>> Hello Ayushman and Ida,
>>> Usually, if multiple students really want to work on a particular
>>> project (and can't/don't want to choose another), there can be
>>> multiple proposals for the same project and we choose the best one.
>>> Sometimes a project can be split up between two students to work on to
>>> minimise conflicts.
>> There are multiple things that need to be addressed here.
>> First, there have been discussions on devel@ about code formatting tools.
>> Sebastian has posted a configuration for the indent program but offhand
>> I don't know where that is. It may be in the documentation.
> I posted about this to Ida. I think it was uncrustify? I think several
> tools have been looked into. No specific tool is required, but we
> should pick the one that best allows us to meet the needs of the
> project.
>> For indent to move forward from here, its impact on the code in a directory
>> that is thought to follow the RTEMS style well would need to be evaluated.
>> Do the rules need to be tweaked to avoid changes? Is the source code actually
>> just not in conformance with published rules? The process here is to evaluate
>> the difference between tool output and existing code and work to close the
>> delta by tweaking rules and fixing code. The end is expected to be that there
>> are a few places where the tool can't produce RTEMS style and we have to
>> discuss adopting something the tool can produce.
>> I don't recall if Sebastian evaluated the llvm formatter and created a configuration
>> for it. In this case, creating a configuration for this tool before evaluating the
>> difference in output would be the path forward. If this formatter is better, then
>> I would like to see an RTEMS style added to their options.
>> With either tool, a factor is integrating it into the development process. I'm
>> not sure what a GSoC project would do about this.
> I think the tool integration is the main piece of GSoC-relevant work,
> as this would involve some level of scripting and automation.
>> So there are two potential projects here. My question is not conflict on
>> project choice, it is whether either is an appropriate GSoC project. With
>> the shorter time frame, I think the scope of the project is in the right ballpark.
>> Is there enough coding? I don't know.
> I'm not currently convinced there is enough coding work for two
> projects in this area. I don't think there would have been enough
> coding work for one project under the old GSoC scope.
> Running the code formatter and submitting patches won't really count
> as "code contributions"

I think the contributions from this project that would add value would be:

1. Finding a tool and a configuration that can do an RTEMS style or an 
acceptable close one.

2. Adding a "check-style" target to our build system.

3. Maybe add some kind of script similar to Linux "" that 
could check whether patches would need changes _before_ they are applied.

Finding stuff that currently doesn't fit our coding style is only a 
small part of it.

Best regards


>> --joel
>>> On Mon, 15 Mar 2021 at 09:45, Ida Delphine <idadelm at> wrote:
>>>> Umm...did you bring up a discussion regarding this project earlier?
> I do not have a record of Ayushman "claiming" this project, and anyway
> we don't allow students to "claim" a project.
>>>> On Mon, 15 Mar 2021, 8:10 am Ayushman Mishra, <ayushvidushi01 at> wrote:
>>>>> Hello Ida delphini AYUSHMAN here , Can you please select any other project for gsoc as I am also currently working on proposal for the same project
>>>>> for gsoc 2021
> Ayushman, this is not a polite request for you to make, in addition it
> would best have been made by direct reply to her email in the same
> thread, not by starting a new e-mail thread. In an open-source
> community, you should not impose yourself on another person. It goes
> against the fundamental ideas of "freedom" that open-source is based
> on. Part of GSoC is exactly about learning this kind of lesson, so
> don't feel too bad about it, but do pay attention to how you interact
> with others and make sure you are respecting their autonomy and
> perspectives.
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at
>>> _______________________________________________
>>> devel mailing list
>>> devel at
>> _______________________________________________
>> devel mailing list
>> devel at
> _______________________________________________
> devel mailing list
> devel at

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
email: christian.mauderer at
phone: +49-89-18 94 741 - 18
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:

More information about the devel mailing list