Re: code reformatting was Re: Regarding gsoc project 3860
Am 15.03.21 um 23:05 schrieb Gedare Bloom: On Mon, Mar 15, 2021 at 6:44 AM Joel Sherrill wrote: On Mon, Mar 15, 2021 at 4:20 AM Hesham Almatary 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 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, 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 -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741
Re: code reformatting was Re: Regarding gsoc project 3860
I am extremely sorry for my behaviour and promise that this won't happen again . Actually I am pretty new to open source community ( I have contributed before but not interacted a lot with other people) and I am really grateful to you for pointing out my mistake , I will definitely make sure about this point while contributing and interacting with others in future. AYUSHMAN On Tue, Mar 16, 2021, 3:35 AM Gedare Bloom wrote: > On Mon, Mar 15, 2021 at 6:44 AM Joel Sherrill 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 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 >
Re: code reformatting was Re: Regarding gsoc project 3860
On Mon, Mar 15, 2021 at 6:44 AM Joel Sherrill wrote: > > > > On Mon, Mar 15, 2021 at 4:20 AM Hesham Almatary > 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 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, >> > 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
code reformatting was Re: Regarding gsoc project 3860
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. 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. 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. --joel > > On Mon, 15 Mar 2021 at 09:45, Ida Delphine wrote: > > > > Umm...did you bring up a discussion regarding this project earlier? > > > > On Mon, 15 Mar 2021, 8:10 am Ayushman Mishra, > 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 > > > > ___ > > 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
Re: Regarding gsoc project 3860
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. On Mon, 15 Mar 2021 at 09:45, Ida Delphine wrote: > > Umm...did you bring up a discussion regarding this project earlier? > > On Mon, 15 Mar 2021, 8:10 am Ayushman Mishra, > 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 > > ___ > 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
Re: Regarding gsoc project 3860
Umm...did you bring up a discussion regarding this project earlier? On Mon, 15 Mar 2021, 8:10 am Ayushman Mishra, 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 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Regarding gsoc project 3860
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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel