On Mon, Mar 15, 2021 at 6:44 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Mon, Mar 15, 2021 at 4:20 AM Hesham Almatary > <hesham.almat...@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 <idad...@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, <ayushvidush...@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@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> _______________________________________________ >> 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
