code reformatting was Re: Regarding gsoc project 3860
Gedare Bloom
gedare at rtems.org
Mon Mar 15 22:05:11 UTC 2021
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"
> --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
More information about the devel
mailing list