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 <ged...@rtems.org> wrote: > 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
