<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 3, 2020 at 7:26 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Jose,<br>
<br>
On 03/01/2020 11:52, Jose Valdez wrote:<br>
>>>> Should be in rtems-tools? If so, in which place?<br>
>>> I think this is the best place given the information I have. I would<br>
>>> need to have more detail before I could provide any specific direction here.<br>
>><br>
>> All host tools are in rtems-tools so at this point, there isn't another place.<br>
>><br>
>> But I agree with Chris. We need more information.<br>
>><br>
> We need to know:<br>
> * Language(s) used for the tool<br>
> * Host requirements to run the tool<br>
> * Licensing of the tool<br>
> <br>
> Putting the pre-qual tools into rtems-tools seems reasonable, but a discussion should happen within the RTEMS Project community/maintainers to do that.<br>
> <br>
> JV02012019, Joel and Gedare:<br>
> <br>
> We need to know:<br>
> * Language(s) used for the tool - python (>= 3.7)<br>
> * Host requirements to run the tool - Debian 10<br>
> * Licensing of the tool - BSD-2-Clause<br>
> <br>
> Please read the section 4 of the document SDD-301.pdf, I am sending in attach (removed to go to rtems devel mailing list!!). This provides an overview of the tool (I think we missed to give you this overview).<br>
> For more information you may also take a look in the SRS-300.pdf and TI-003 (just the conclusions on each section).<br>
> Note that the information presented in these documents is subjected to be changed, but as I said, the idea is for you to have a better understanding about the big picture of the project. The details will be discussed (and iterated) alongside the project execution.<br>
<br>
the aim is to write all tools in the ESA pre-qualification activity in <br>
Python. Derivatives of existing stuff will use the respective license. <br>
New stuff will use the BSD-2-Clause license for code and CC-BY-SA-4.0 <br>
for documentation.<br>
<br>
 From an RTEMS Project point of view, project-specific documentation is <br>
irrelevant in general. It can be used as a complementary material to <br>
explain things intended for integration, however, all content relevant <br>
to things integrated in the RTEMS Project must move to the right places <br>
in the RTEMS Project.<br>
<br>
We have to settle on a specific Python version. Since Doorstop 2.0.post2 <br>
is already selected as the tool for requirements management and it <br>
requires at least Python 3.6 I think it makes sense to use this version <br>
as well for new tools. In contrast to the build system I think a Python <br>
2 compatibility is unnecessary.<br>
<br>
Tools which belong also to the work flow of an RTEMS user, e.g. the <br>
RTEMS Tester, should still work with Python 2.<br>
<br>
The decisions, justification, and requirements with respect to the tool <br>
language selection should be recorded in the RTEMS Software Engineering <br>
manual.<br>
<br>
Once a tool language is selected. We need a coding style and standard. <br>
We should choose an existing one, e.g.<br>
<br>
<a href="https://www.python.org/dev/peps/pep-0008/" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0008/</a><br>
<br>
There should be tools to check the coding style automatically. I don't <br>
want the situation we have with the RTEMS sources. For Python there are <br>
plenty of tools, guides, and documentation available. We just have to <br>
pick some for the RTEMS Project and document this in the RTEMS Software <br>
Engineering manual.<br>
<br>
The compatible Python versions (e.g. 3.6+), coding style (e.g. black -l <br>
80), documentation style (e.g. pydocstyle), test approach (standard <br>
Python unittest and unittest.mock), static analysis (e.g. mypy and <br>
pylint), code coverage, use of third-party packages, etc. need to be <br>
discussed with the RTEMS Project and the conclusions should be added to <br>
the RTEMS Software Engineering manual.<br>
<br>
Running the checkers, test suites, code coverage, etc. should be done <br>
though the build system (in rtems-tools this is waf). The Doorstop <br>
project is a good example how this can be set up.<br>
<br>
If you look at the current RTEMS Software Engineering manual you will <br>
find next to nothing with respect to Python code. You can set now the <br>
standards (after discussion on <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>). You should do this <br>
before you send the first line of Python code for review.<br></blockquote><div><br></div><div>I agree completely on the proposed approach with Python tools.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Once the frame for Python development is settled. We need a high level <br>
description of the purpose of the tools, the inputs and the outputs. <br>
This high level description should be integrated in the RTEMS Project <br>
documentation. If you want to get things integrated in the RTEMS Project <br>
then you have make sure that it is good and general enough so that <br>
others can continue to work on it. In the worst case everything should <br>
be maintainable by the RTEMS Project without you in the future.<br></blockquote><div><br></div><div>Describing the purpose, inputs and outputs, and high level description should</div><div>go a long way to having a theory of operation for the tools. It is important to</div><div>know what software engineering purpose the tool satisfies and its role in</div><div>the pre-qualification workflow.</div><div><br></div><div>Thanks for taking the time Sebastian for the nice write up.</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div></div>