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
Re: [Project #3860]
On Fri, Feb 28, 2020 at 5:34 AM Christian Mauderer wrote: > > Hello Anmol, > > On 28/02/2020 10:31, Anmol Mishra wrote: > > Hello, > > I was going through the list of potential projects for GSoC 2020, I love > > working with automation tools and "Code Formatting and Style Check for > > RTEMS score" looks exciting to me. I saw you edited the wiki and the > > owner was not mentioned so pinging you for the same. > > I'm not sure whether we already assigned someone. But that is a topic > that could be handled by multiple mentors. So your best bet is to ask on > the list. > > > I have read the requirements and hurdles, I have a question that > > 1. "Is there any tool/procedure currently being considered as an option?" > > Not as far as I'm concerned. You might want to have a look at the wiki. > I think there have been some notes for code formatters a few years back. > I only know about https://devel.rtems.org/wiki/Developer/Coding/Conventions#Tools Additionally, there should be some git hooks for style check/enforcement, but with the ability to override the hooks (e.g., if we need to break the style rules for some good exceptions). > > 2. "What is the timeframe I should look in the mail archive like the > > past 3 months?" > > That topic was created during a recent discussion regarding style > checking for Python. It can only be a few weeks now. But there haven't > been much details about it. > +1 should be quite recent discussion. I did a quick search to help you out. Many of the key points are made in a good thread to read through with subject: "Requirement Document generator tool" from December through February. https://lists.rtems.org/pipermail/devel/2019-December/056455.html https://lists.rtems.org/pipermail/devel/2020-January/056706.html https://lists.rtems.org/pipermail/devel/2020-February/057057.html and then another thread subject: "Tool Roadmap for the RTEMS Pre-Qualification" has a superset of issues including Python conventions: https://lists.rtems.org/pipermail/devel/2020-February/057246.html > Best regards > > Christian > > > > > It goes without saying how much this means to me. I will be submitting 2 > > project proposals and don't want to waste time and start with draft > > proposal asap. Looking forward to hearing from you. > > > > Regards > > Anmol > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > > > -- > > embedded brains GmbH > Herr Christian Mauderer > Dornierstr. 4 > D-82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > Phone: +49-89-18 94 741 - 18 > Fax: +49-89-18 94 741 - 08 > PGP: Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > ___ > 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: [Project #3860]
Hello Anmol, On 28/02/2020 10:31, Anmol Mishra wrote: > Hello, > I was going through the list of potential projects for GSoC 2020, I love > working with automation tools and "Code Formatting and Style Check for > RTEMS score" looks exciting to me. I saw you edited the wiki and the > owner was not mentioned so pinging you for the same. I'm not sure whether we already assigned someone. But that is a topic that could be handled by multiple mentors. So your best bet is to ask on the list. > I have read the requirements and hurdles, I have a question that > 1. "Is there any tool/procedure currently being considered as an option?" Not as far as I'm concerned. You might want to have a look at the wiki. I think there have been some notes for code formatters a few years back. > 2. "What is the timeframe I should look in the mail archive like the > past 3 months?" That topic was created during a recent discussion regarding style checking for Python. It can only be a few weeks now. But there haven't been much details about it. Best regards Christian > > It goes without saying how much this means to me. I will be submitting 2 > project proposals and don't want to waste time and start with draft > proposal asap. Looking forward to hearing from you. > > Regards > Anmol > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[Project #3860]
Hello, I was going through the list of potential projects for GSoC 2020, I love working with automation tools and "Code Formatting and Style Check for RTEMS score" looks exciting to me. I saw you edited the wiki and the owner was not mentioned so pinging you for the same. I have read the requirements and hurdles, I have a question that 1. "Is there any tool/procedure currently being considered as an option?" 2. "What is the timeframe I should look in the mail archive like the past 3 months?" It goes without saying how much this means to me. I will be submitting 2 project proposals and don't want to waste time and start with draft proposal asap. Looking forward to hearing from you. Regards Anmol ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
