Re: Enabling Buildbot 'responsible user' emails.

[Sebastian Huber]

On 06/02/2020 00:11, Chris Johns wrote:


On 6/2/20 10:00 am, Amar Takhar wrote:

On 2020-02-06 08:31 +1100, Chris Johns wrote:


Can we enable this for one BSP from each tier 1 architectures?

Yes, can you provide a list?

The master list is here ...

https://git.rtems.org/rtems-tools/tree/config/rtems-bsps-tiers.ini


I would use different criteria to select BSPs for buildbot runs. They 
should at least cover the maintained architectures (arm, powerpc, riscv, 
and sparc). Using simulator BSPs has the benefit that you can run also 
the test suite without having access to the hardware. This helps to 
debug issues. I think the current selection is already quite good. Maybe 
we should just add riscv/rv64imafdc_medany as 64-bit BSP to the list.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Enabling Buildbot 'responsible user' emails.

[Amar Takhar]

On 2020-02-07 16:17 +1100, Chris Johns wrote:
> 
> Could we build an "always must build" BSP and if it builds a wider selection 
> are
> built? The beaglebone black is my pick.

That's the way it already works now and has for years.

Look at the waterfall the process is:

  1. Build snapshot
  2. Build sparc/erc32
  3. If #2 passes trigger 
  4. If #3 passes build "stable" snapshot.

You can see this by viewing: https://buildbot.rtems.org/#/waterfall and looking 
at the timeline to see the order.


> This would avoid a issue in the common code or buildbot needing updated tools
> from generating the same message a number of times.

Yes again it already works this way and has for the last 6 years. :)


> Note, it cannot be a SPARC BSP because it is not a tier 1 architecture as no
> hardware test results has been published .

No idea nobody has ever mentioned anything and it's clear on Buildbot that the 
CHECK BSP is what is used... this is what was given to me a very long time ago.

Which one should it be now?  Can everyone agree one one?


Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Enabling Buildbot 'responsible user' emails.

[Chris Johns]

On 7/2/20 4:05 pm, Amar Takhar wrote:
> On 2020-02-06 08:03 -0700, Gedare Bloom wrote:
>> I agree with what you say. (And appreciate the unfunded work.)
>> So, if this "Responsible User" email policy goes into effect, we also
>> need some additional policies for developers to help prevent the
>> "RTEMS Horde of Broken Builds" (TM) emails especially from going
>> outside of the core developers who at least might expect the noise.
> 
> I don't agree, honestly I also don't agree with creating issues before they 
> happen.  Once we see developers get flooded with emails let's deal with how 
> to 
> resolve that when it does happen.
> 
> Let's not forget the purpose of Buildbot is to make scenarios like this 
> annoying, we shouldn't be breaking the build. :)

Could we build an "always must build" BSP and if it builds a wider selection are
built? The beaglebone black is my pick.

This would avoid a issue in the common code or buildbot needing updated tools
from generating the same message a number of times.

Note, it cannot be a SPARC BSP because it is not a tier 1 architecture as no
hardware test results has been published .

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Enabling Buildbot 'responsible user' emails.

[Amar Takhar]

On 2020-02-06 08:03 -0700, Gedare Bloom wrote:
> I agree with what you say. (And appreciate the unfunded work.)

Thank you.


> I still have reservations about the possibility to generate 250 emails
> all basically the same. Perhaps developers/committers should test
> every commit. Sometimes though we have purposefully allowed one commit
> to be broken followed by the next that fixes it. (Of course, this
> makes bisecting harder, so maybe it is bad practice.) I think the one
> exception that should allow this practice is when we import code from
> elsewhere, and then fix it up after.  This is also the case that would
> potentially cause some unwitting soul to receive this blast of emails.

Well, broken commits shouldn't be a thing in any repository.  I haven't been a 
part of any development project that allows that in 5+ years  They're all 
check-before-commit now to ensure master builds 100% of the time.  This is 
extremely important for future development on longterm projects.

I do see your point but it's not a feature I'd like to support.


> So, if this "Responsible User" email policy goes into effect, we also
> need some additional policies for developers to help prevent the
> "RTEMS Horde of Broken Builds" (TM) emails especially from going
> outside of the core developers who at least might expect the noise.

I don't agree, honestly I also don't agree with creating issues before they 
happen.  Once we see developers get flooded with emails let's deal with how to 
resolve that when it does happen.

Let's not forget the purpose of Buildbot is to make scenarios like this 
annoying, we shouldn't be breaking the build. :)


> Essentially a statement like:
> 1. All committers will test each commit from other authors to ensure
> they build on (Tier 1?) architectures before pushing.

Chris has already suggested to limit this to tier1 architectures and I agree 
with this.


> We already have similar statements about submissions, but it is good
> to cross-check committers. I'm not quite sure if we have codified any
> of these processes. A quick search only yields:
> https://docs.rtems.org/branches/master/eng/vc-authors.html#commands
> https://devel.rtems.org/wiki/Developer/Contributing#Testing

Thanks.

I'll be sending another email about submitting diffs to Buildbot for building 
in 
the next few days.


Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Enabling Buildbot 'responsible user' emails.

[Amar Takhar]

On 2020-02-06 07:44 +0100, Christian Mauderer wrote:

> Like already said: I'm not against sending the mails. And the situation
> is quite unlikely in RTEMS core. But we should be aware of the
> possibility before enabling such an option.

Agreed and thank you for highlighting this.  While I am sure of how it works I 
will be certain to check it to make double sure.


> The alternative could be to have a whitelist that is automatically
> updated by every mail that is sent to the mailing lists. But that would
> require buildbot to support a whitelist and it would require a script to
> get the first "From" header for each mail on the list.

Yes, I had already thought about this when you first mentioned it.  For 
instance 
limiting emails to those who have accounts on trac or are subscribed to our 
mailing lists.


> Thanks for all your hard work with buildbot and similar infrastructure.

No problem and thank you. :)


Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Changed print statement in sample executable hello

[Gedare Bloom]

Thanks.

On Thu, Feb 6, 2020, 11:16 AM Ayush Dwivedi <21cencturyay...@gmail.com>
wrote:

> ---
>  testsuites/ada/sptests/sp19/Makefile | 2 --
>  testsuites/samples/hello/init.c  | 2 +-
>  2 files changed, 1 insertion(+), 3 deletions(-)
>  delete mode 100644 testsuites/ada/sptests/sp19/Makefile
>
> diff --git a/testsuites/ada/sptests/sp19/Makefile
> b/testsuites/ada/sptests/sp19/Makefile
> deleted file mode 100644
> index 7d4019fd39..00
> --- a/testsuites/ada/sptests/sp19/Makefile
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -sptest.adb: sptest.adp
> -   m4 < $< > $@
> diff --git a/testsuites/samples/hello/init.c
> b/testsuites/samples/hello/init.c
> index 34ded37c55..25dc5ca5f5 100644
> --- a/testsuites/samples/hello/init.c
> +++ b/testsuites/samples/hello/init.c
> @@ -22,7 +22,7 @@ static rtems_task Init(
>  {
>rtems_print_printer_fprintf_putc(&rtems_test_printer);
>TEST_BEGIN();
> -  printf( "Hello World\n" );
> +  printf( "Zombies Ate My Brains!!!\n" );
>TEST_END();
>rtems_test_exit( 0 );
>  }
> --
> 2.23.0
>
> ___
> 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

[PATCH] Changed print statement in sample executable hello

[Ayush Dwivedi]

---
 testsuites/ada/sptests/sp19/Makefile | 2 --
 testsuites/samples/hello/init.c  | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)
 delete mode 100644 testsuites/ada/sptests/sp19/Makefile

diff --git a/testsuites/ada/sptests/sp19/Makefile 
b/testsuites/ada/sptests/sp19/Makefile
deleted file mode 100644
index 7d4019fd39..00
--- a/testsuites/ada/sptests/sp19/Makefile
+++ /dev/null
@@ -1,2 +0,0 @@
-sptest.adb: sptest.adp
-   m4 < $< > $@
diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index 34ded37c55..25dc5ca5f5 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -22,7 +22,7 @@ static rtems_task Init(
 {
   rtems_print_printer_fprintf_putc(&rtems_test_printer);
   TEST_BEGIN();
-  printf( "Hello World\n" );
+  printf( "Zombies Ate My Brains!!!\n" );
   TEST_END();
   rtems_test_exit( 0 );
 }
-- 
2.23.0

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help with proof submission for Contribution Eligibilty

[Gedare Bloom]

Hello Ayush,

On Thu, Feb 6, 2020 at 3:51 AM Vaibhav Gupta  wrote:
>
>
>
> On Thu, Feb 6, 2020, 4:15 PM Ayush Dwivedi <21cencturyay...@gmail.com> wrote:
>>
>> Hello everyone,
>>
>> I am new to RTEMS community. I wish to contribute to the RTEMS project. I 
>> read on the RTEMS gsoc getting started page that I am required to submit a 
>> proof that I can contribute. Modifying the sample executable hello.exe  
>> source code along with the screenshot of it being tested on gdb is needed so 
>> I changed the print statement of the sample and ran it on gdb. I have took 
>> the screenshot as asked and made a patch file as required. I need to know 
>> where and how to send it.
>
Please email it to me with CC to j...@rtems.org and chr...@rtems.org.

> Use 'git send-email' to send patches. You will need to set up smtp for this 
> in gitconfig file.
>
For patches to merge this is true. For GSoC proof it is preferred to
have direct private email to Org Admins.

> --Vaibhav
>>
>>
>> Regards,
>> Ayush Dwivedi
>>
>>
>> ___
>> 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: Enabling Buildbot 'responsible user' emails.

[Gedare Bloom]

On Thu, Feb 6, 2020 at 8:20 AM Sebastian Huber
 wrote:
>
> On 06/02/2020 16:03, Gedare Bloom wrote:
>
> > So, if this "Responsible User" email policy goes into effect, we also
> > need some additional policies for developers to help prevent the
> > "RTEMS Horde of Broken Builds" (TM) emails especially from going
> > outside of the core developers who at least might expect the noise.
> I think we should never send emails automatically to someone who is not
> subscribed to some RTEMS Project service. Maybe only email addresses
> subscribed to the devel@rtems.org mailing list should be used.

Yes, that would be a good cross-check. It would help to avoid
mistakenly spamming someone.

We should also make the commit/push policy clearer, but I think we all
kind of understand that already.

Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Enabling Buildbot 'responsible user' emails.

[Sebastian Huber]

On 06/02/2020 16:03, Gedare Bloom wrote:


So, if this "Responsible User" email policy goes into effect, we also
need some additional policies for developers to help prevent the
"RTEMS Horde of Broken Builds" (TM) emails especially from going
outside of the core developers who at least might expect the noise.
I think we should never send emails automatically to someone who is not 
subscribed to some RTEMS Project service. Maybe only email addresses 
subscribed to the devel@rtems.org mailing list should be used.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Rework of Initialization Chapter in BSP Howto

[Gedare Bloom]

On Thu, Feb 6, 2020 at 12:22 AM Chris Johns  wrote:
>
> On 2020-02-06 17:15, Sebastian Huber wrote:
> > On 05/02/2020 22:13, Chris Johns wrote:
> >>
> >> After all one of roles of the RTEMS Foundation is education.
> >
> > I added a ticket for this:
> >
> > https://devel.rtems.org/ticket/3867
> >
>
> Thanks
> Chris
+1

As someone who got started in RTEMS by doing a new port, I spent a
long time in this guide. It is indispensable and could definitely be a
helpful tool for education.

I'll try to find time to look into it myself.

> ___
> 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: Enabling Buildbot 'responsible user' emails.

[Gedare Bloom]

On Wed, Feb 5, 2020 at 10:31 PM Amar Takhar  wrote:
>
> On 2020-02-05 20:28 -0700, Gedare Bloom wrote:
> > I would like it to be a single email to indicate there is a new
> > breakage. Enough to indicate "hey go take a look at the full build
> > results! something is wrong here"
>
> That's what it does.  Breakage isn't always the same across builds.  Waiting
> until the end to send a 'summarised' email would take hours if not a day.  
> Soon
> as the first build is broken the email is sent out.
>
> If we had more hardware to build BSPs in a more parallel fashion this could be
> possible right now it's out of our means.
>
>
> > It should be opt-in to the full results.
>
> That is what submitting source for the repository is.  An opt-in to getting an
> email letting you know that your changes have broken something.
>
> It's not very often someone is going to break every BSP.  I'd rather do this 
> and
> deal with if and when it's a problem.  The only feasible way that could happen
> is if someone doesn't test their build.
>
> The second way is for someone to submit code that requires a tool upgrade.  
> That
> can be avoided by notifying me that the tools need to be upgraded.
>
> Right now all this work is unfunded I do have a design and plan to have the
> tools automatically build continuously which would avoid the second problem
> entirely.
>
I agree with what you say. (And appreciate the unfunded work.)

I still have reservations about the possibility to generate 250 emails
all basically the same. Perhaps developers/committers should test
every commit. Sometimes though we have purposefully allowed one commit
to be broken followed by the next that fixes it. (Of course, this
makes bisecting harder, so maybe it is bad practice.) I think the one
exception that should allow this practice is when we import code from
elsewhere, and then fix it up after.  This is also the case that would
potentially cause some unwitting soul to receive this blast of emails.

So, if this "Responsible User" email policy goes into effect, we also
need some additional policies for developers to help prevent the
"RTEMS Horde of Broken Builds" (TM) emails especially from going
outside of the core developers who at least might expect the noise.

Essentially a statement like:
1. All committers will test each commit from other authors to ensure
they build on (Tier 1?) architectures before pushing.

We already have similar statements about submissions, but it is good
to cross-check committers. I'm not quite sure if we have codified any
of these processes. A quick search only yields:
https://docs.rtems.org/branches/master/eng/vc-authors.html#commands
https://devel.rtems.org/wiki/Developer/Contributing#Testing

>
> Amar.
> ___
> 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: Ticket #3515

[Bran S]

On Tue, 4 Feb 2020 at 13:28, Vijay Kumar Banerjee 
wrote:

>
>
> On Tue, Feb 4, 2020, 11:33 AM Bran S  wrote:
>
>> On Saturday, 1 February 2020, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>> >
>> >
>> >
>> > On Sat, Feb 1, 2020 at 9:31 PM Bran S  wrote:
>> >>
>> >> On Sat, 1 Feb 2020 at 18:44, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>> >> >
>> >> > On Sat, Feb 1, 2020 at 12:57 PM Bran S  wrote:
>> >> >>
>> >> >> On Thu, 30 Jan 2020 at 05:52, Chris Johns  wrote:
>> >> >> >
>> >> >> > On 29/1/20 7:03 pm, Bran S wrote:
>> >> >> > > Hi Guys,
>> >> >> > >
>> >> >> > > I am trying to solve #3515
>> >> >> > > https://devel.rtems.org/ticket/3515 <
>> https://devel.rtems.org/ticket/3515>
>> >> >> >
>> >> >> > Nice and thanks.
>> >> >> >
>> >> >> > > For this issue covoar is required.
>> >> >> > >
>> >> >> > > So I cloned https://git.rtems.org/rtems-tools/ <
>> https://git.rtems.org/rtems-tools/>
>> >> >> > > This is my directory structure:
>> >> >> > > $HOME/quick-start/src/rtems - Main RTEMS repo
>> >> >> > > $HOME/quick-start/src/rsb - Source Builder
>> >> >> > > $HOME/quick-start/src/rtems-tools - The one that I have
>> recently cloned
>> >> >> > >
>> >> >> > > But running `rtems-test --list-bsps` inside
>> '$HOME/quick-start/src/rtems-tools'
>> >> >> > > gives "error: RTEMS Toolkit python wrapper not found, plrease
>> report"
>> >> >> > >
>> >> >> > > Any ideas on how to resolve this error ?
>> >> >> >
>> >> >> > What does `type rtems-test` say?
>> >> >> >
>> >> >> > Have you built a set of sparc tools?
>> >> >> > Have you build the leon3 BSP and all the tests?
>> >> >> >
>> >> >> > I am not sure what happens if the `rtems-test` is run in the
>> source tree while
>> >> >> > picking up a version from your path. Maybe `./tester/rtems-test
>> ...` works?
>> >> >>
>> >> > Hi Bran,
>> >> >
>> >> > Thanks for taking up this ticket.
>> >> >>
>> >> >> It is now working my $PATH was wrongly set with rtems/4.11 instead
>> of rtems/5.
>> >> >> I have corrected it. It now contains '$HOME/quick-start/rtems/5/bin'
>> >> >>
>> >> > Nice.
>> >> >>
>> >> >> Moving on to the next problem:
>> >> >>
>> https://devel.rtems.org/wiki/GCI/Documentation/CoverageAnalysis/Coverage#RunningRTEMS-TESTERforCoverageanalysis
>> >> >> I was reading this to know more about covoar.
>> >> >> So as mentioned above I ran
>> >> >>
>> >> >> `rtems-test --rtems-tools=/home/user45/quick-start/rtems/5/
>> >> >> --log=coverage_analysis.log --no-clean --coverage=score
>> >> >> --rtems-bsp=leon3-qemu-cov
>> >> >>
>> /home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/samples/hello.exe`
>> >> >>
>> >> >> And the output was: https://paste.debian.net/1128608/
>> >> >> `qemu-system-sparc` not being installed seems to be the cause for
>> the error.
>> >> >>
>> >> >> So I followed suggestion found here:
>> >> >> https://lists.rtems.org/pipermail/users/2018-January/065583.html
>> >> >> Ran the commands as:
>> >> >>
>> >> >> $ cd /quick-start/src/rsb/rtems/
>> >> >> The rsb directory contains rtems source builder.
>> >> >>
>> >> >> $ ../source-builder/sb-set-builder
>> --prefix=$HOME/quick-start/rtems/5
>> >> >> devel/qemu.bset
>> >> >>
>> >> > You need devel/qemu-couverture.bset but while trying to build it, I
>> see the same error
>> >> > as you see with qemu.bset
>> >> >>
>> >> >> Running this further gives errors and reports it into
>> >> >> 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt'
>> >> >> Full output of above command is at:
>> https://paste.debian.net/1128609/
>> >> >>
>> >> >> The content of 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt' is
>> >> >> here: https://paste.debian.net/1128610/
>> >> >>
>> >> >> In file 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt' (at
>> >> >> https://paste.debian.net/1128610/) the first error occurs at line
>> 385,
>> >> >> which is:
>> >> >>
>> >> >> ../../glib-2.39.3/glib/gdate.c:2497:7: error: format not a string
>> >> >> literal, format string not checked [-Werror=format-nonliteral]
>> >> >>tmplen = strftime (tmpbuf, tmpbufsize, locale_format, &tm);
>> >> >>^~
>> >> >>   CC   libglib_2_0_la-gdir.lo
>> >> >>   CC   libglib_2_0_la-genviron.lo
>> >> >> cc1: some warnings being treated as errors
>> >> >> Makefile:1782: recipe for target 'libglib_2_0_la-gdate.lo' failed
>> >> >> make[4]: *** [libglib_2_0_la-gdate.lo] Error 1
>> >> >>
>> >> >> This happens to be a known error/bug (Ref:
>> >> >> https://bugs.freedesktop.org/show_bug.cgi?id=95326)
>> >> >> and a patch is available for it here:
>> >> >>
>> https://gitlab.gnome.org/GNOME/glib/commit/8cdbc7fb2c8c876902e457abe46ee18a0b134486
>> >> >>
>> >> >> Following the patch I manually made changes into
>> >> >>
>> '$HOME/quick-start/src/rsb/rtems/build/glib-2.39.3-x86_64-linux-gnu-1/glib-2.39.3/glib/gdate.c'
>> >> >>
>> >> >> But the problem is that as soon as I run
>> >> >> `../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
>> >> >> devel/qemu.bset`
>> >> >> My manual chan

Re: Need help with proof submission for Contribution Eligibilty

[Vaibhav Gupta]

On Thu, Feb 6, 2020, 4:15 PM Ayush Dwivedi <21cencturyay...@gmail.com>
wrote:

> Hello everyone,
>
> I am new to RTEMS community. I wish to contribute to the RTEMS project. I
> read on the RTEMS gsoc getting started page that I am required to submit a
> proof that I can contribute. Modifying the sample executable hello.exe
> source code along with the screenshot of it being tested on gdb is needed
> so I changed the print statement of the sample and ran it on gdb. I have
> took the screenshot as asked and made a patch file as required. I need to
> know where and how to send it.
>
Use 'git send-email' to send patches. You will need to set up smtp for this
in gitconfig file.

--Vaibhav

>
> Regards,
> Ayush Dwivedi
>
>
> ___
> 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

Need help with proof submission for Contribution Eligibilty

[Ayush Dwivedi]

Hello everyone,

I am new to RTEMS community. I wish to contribute to the RTEMS project. I
read on the RTEMS gsoc getting started page that I am required to submit a
proof that I can contribute. Modifying the sample executable hello.exe
source code along with the screenshot of it being tested on gdb is needed
so I changed the print statement of the sample and ran it on gdb. I have
took the screenshot as asked and made a patch file as required. I need to
know where and how to send it.

Regards,
Ayush Dwivedi
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Requirement Document generator tool

[Christian Mauderer]

Hello Chris,

please let me pick up the discussion again so that we manage to come
to a conclusion. Like Matthias said oflist, we are trying to address
the problem of the missing project overview in a separate thread. But
it would be really relevant to get a result for the python topics.

Again: In my view the discussion has been triggered by the
pre-qualification efforts but it isn't limited to it. Having standards
for how to handle python tools would make adding and maintaining new
tools simpler in any case.

Although we will have some more topics (test approach, static
analysis, documentation style, ...) I'll try to concentrate on the
style issues for now. The other topics are much less relevant for the
existing code.

I already said that in another mail but please let me repeat it again:
My target wouldn't be to reformat existing code. My target is to find
something that would be acceptable for all new code and that is
similar enough that existing code is still readable and maybe can
converted when a change is necessary for some other reason. PEP 8 even
suggests to not reformat code if it predates a coding standard:

https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

Google style doesn't express it that directly but there are "Parting
Words" too that tell basically the same:

https://google.github.io/styleguide/pyguide.html#4-parting-words

Below I added some answers to the code locations that you specifically
mentioned before.

On 28/01/2020 11:41, Chris Johns wrote:
> On 28/1/20 8:14 pm, Christian Mauderer wrote:
>> On 28/01/2020 01:42, Chris Johns wrote:
>>> On 28/1/20 10:48 am, Joel Sherrill wrote:
 On Mon, Jan 27, 2020 at 4:18 PM Chris Johns >>> > wrote:

 On 24/1/20 9:57 pm, Jose Valdez wrote:
 > In fact these tools target the pre-qualified project.

 Do you see this as different to the RTEMS project?

 > Since it was Sebastian who suggested to create this set of
python tools,

 I think Sebastian is wanting a smooth path for these tools into
the project.

 > I think the idea was to standardize the use of python not
only for this
 project, but also for other python written code in RTEMS
community. This has
 the advantages that every written python code is standard, but
has the
 drawbacks:
 >
 > -> old written code would need to be adapted to the standards.

 How different to the proposed coding standard is the existing
code? Why not base
 the coding standard on what exists in the code base?

 This is a very important question.

 Have you evaluated the size of the task to update the existing
code? How would
 get such changes for the rtems-tools and the RSB be tested and
integrated back
 into the project? This apporach seems like a huge review task
for me.

 It could be or it may turn out that there isn't much changed.
Without someone
 running the reformatter and reporting, we won't know.
>>>
>>> Running a reformatter may give you an idea of the scale however I
have some
>>> concerns as Python's logic is based on indent levels and a missed
level changes
>>> the logic. I am not sure how you know such a tool is safe to use
unless you
>>> review all the changes.
>>
>> To get some statistics for that I tried using yapf on the rtems-tools
>> repo. I excluded everything with  "patch-gdb-python", "tftpy" and
>> "asciidoc" in the name. You can see the yapf call in the commit message.
>
> The doxygen is from waf. Thomas knows how to write python.
>
>> Google style:
>>
https://gist.githubusercontent.com/c-mauderer/18746eaa8f3a077adddfe35c1f7b5194/raw/f8202a53ca043d23732d79ab217071e975dc35ad/0001-FIXME-Format-in-Google-style.patch
>>
>> PEP8 Style:
>>
https://gist.githubusercontent.com/c-mauderer/18746eaa8f3a077adddfe35c1f7b5194/raw/c97c77762f65041d9244bc8bc64b90ec698735bf/0001-FIXME-Reformat-using-PEP8.patch
>>
>> In both cases it's about 3000 lines removed and 3700 lines added.
>>
>> Without having a look at each line: Most seems to be just the normal
>> formatting stuff. Some lines are too long. Some spaces missing around
>> operators or spaces where they shouldn't be.
>
> And then there is removal of spaces on default args ...
>
> -def section_macro_map(self, section, nesting_level = 0):
> +def section_macro_map(self, section, nesting_level=0):

How strong do you feel about these changes? Like noted in another mail
it's one of the official Python PEPs (PEP 8) that suggests to have no
spaces here. See:

https://www.python.org/dev/peps/pep-0008/#other-recommendations

>
> I prefer spaces as it is consistent with other uses of spaces around
operators.
>
>> Some lists written with
>> more or less line breaks.
>
> Yes to make them readable. This is on purpose. I do not agree with this ..
>
> -return cfgs + ['objcopy',
> -   'arc