code reformatting was Re: Regarding gsoc project 3860

[Ayushman Mishra]

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 <gedare at rtems.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210316/0550a791/attachment-0001.html>