Am 15.03.21 um 23:05 schrieb Gedare Bloom:
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"
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 <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
--
--------------------------------------------
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 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
