code reformatting was Re: Regarding gsoc project 3860

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 rtems.org> wrote:
>>
>>
>>
>> On Mon, Mar 15, 2021 at 4:20 AM Hesham Almatary <hesham.almatary at cl.cam.ac.uk> 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 "checkpatch.pl" 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

Christian

> 
>> --joel
>>
>>>
>>>
>>> On Mon, 15 Mar 2021 at 09:45, Ida Delphine <idadelm at gmail.com> 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 gmail.com> wrote:
>>>>>
>>>>> AYUSHMAN MISHRA
>>>>>
>>>>> 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
>>>>> https://devel.rtems.org/ticket/3860 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 rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
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:
https://embedded-brains.de/datenschutzerklaerung/