Hello Jose,
On 03/01/2020 11:52, Jose Valdez wrote:
Should be in rtems-tools? If so, in which place?
I think this is the best place given the information I have. I would
need to have more detail before I could provide any specific direction here.
All host tools are in rtems-tools so at this point, there isn't another place.
But I agree with Chris. We need more information.
We need to know:
* Language(s) used for the tool
* Host requirements to run the tool
* Licensing of the tool
Putting the pre-qual tools into rtems-tools seems reasonable, but a discussion
should happen within the RTEMS Project community/maintainers to do that.
JV02012019, Joel and Gedare:
We need to know:
* Language(s) used for the tool - python (>= 3.7)
* Host requirements to run the tool - Debian 10
* Licensing of the tool - BSD-2-Clause
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).
For more information you may also take a look in the SRS-300.pdf and TI-003
(just the conclusions on each section).
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.
the aim is to write all tools in the ESA pre-qualification activity in
Python. Derivatives of existing stuff will use the respective license.
New stuff will use the BSD-2-Clause license for code and CC-BY-SA-4.0
for documentation.
From an RTEMS Project point of view, project-specific documentation is
irrelevant in general. It can be used as a complementary material to
explain things intended for integration, however, all content relevant
to things integrated in the RTEMS Project must move to the right places
in the RTEMS Project.
We have to settle on a specific Python version. Since Doorstop 2.0.post2
is already selected as the tool for requirements management and it
requires at least Python 3.6 I think it makes sense to use this version
as well for new tools. In contrast to the build system I think a Python
2 compatibility is unnecessary.
Tools which belong also to the work flow of an RTEMS user, e.g. the
RTEMS Tester, should still work with Python 2.
The decisions, justification, and requirements with respect to the tool
language selection should be recorded in the RTEMS Software Engineering
manual.
Once a tool language is selected. We need a coding style and standard.
We should choose an existing one, e.g.
https://www.python.org/dev/peps/pep-0008/
There should be tools to check the coding style automatically. I don't
want the situation we have with the RTEMS sources. For Python there are
plenty of tools, guides, and documentation available. We just have to
pick some for the RTEMS Project and document this in the RTEMS Software
Engineering manual.
The compatible Python versions (e.g. 3.6+), coding style (e.g. black -l
80), documentation style (e.g. pydocstyle), test approach (standard
Python unittest and unittest.mock), static analysis (e.g. mypy and
pylint), code coverage, use of third-party packages, etc. need to be
discussed with the RTEMS Project and the conclusions should be added to
the RTEMS Software Engineering manual.
Running the checkers, test suites, code coverage, etc. should be done
though the build system (in rtems-tools this is waf). The Doorstop
project is a good example how this can be set up.
If you look at the current RTEMS Software Engineering manual you will
find next to nothing with respect to Python code. You can set now the
standards (after discussion on devel@rtems.org). You should do this
before you send the first line of Python code for review.
Once the frame for Python development is settled. We need a high level
description of the purpose of the tools, the inputs and the outputs.
This high level description should be integrated in the RTEMS Project
documentation. If you want to get things integrated in the RTEMS Project
then you have make sure that it is good and general enough so that
others can continue to work on it. In the worst case everything should
be maintainable by the RTEMS Project without you in the future.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
