Requirement Document generator tool
Chris Johns
chrisj at rtems.org
Wed Jan 29 22:48:59 UTC 2020
On 29/1/20 7:40 pm, Christian Mauderer wrote:
> On 28/01/2020 23:15, Chris Johns wrote:
>> On 28/1/20 10:22 pm, Christian Mauderer wrote:
>>> I'm quite indifferent which style we use
>>
>> But you are arguing a position, such as ...
>>
>>> but do you really think that it
>>> is a good idea to roll our own RTEMS-Python-style instead of using one
>>> of the big ones (like PEP8, Google or some other that might is a better
>>> fit for existing code). Rolling our own would lead to:
>>>
>>> 1. Long discussions about what is THE RIGHT STYLE (already started in
>>> this mail).
>>>
>>> 2. A lot of problems that there is no tool that formats or checks
>>> whether code is in THE RIGHT STYLE.
>>>
>>> 3. More discussions later because some other developer thinks that THE
>>> RIGHT STYLE is wrong.
>
> You are right that I argue against home-grown styles. I learned that
> style discussions are quite similar to religious discussions. Everyone
> beliefs that his style is the only right one. Using a big one makes it
> simpler to avoid discussions because a lot of people know it.
And yet you inherit issues a large organisation cannot correct because
historically a style is difficult to change and they are wedged. They need to be
reviewed and evaluated.
> Please don't get me wrong: I'm OK with another style too. The relevant
> result is that we have _one_ style in RTEMS that can be automatically
> checked.
I find it interesting this view is OK for Python and the tools and yet we do not
have automatic checking for the score's C. Or do we?
> That also will make patch review simpler because we as
> maintainers don't have to do the style review by hand.
This is often more about those coding than those reviewing.
>> I wrote the code, I know it and I need to maintain it. All I am asking is if
>> pre-qual wants rules then I suggest they find some common ground.
>
> I agree that it is a good idea to find something that is acceptable for all.
>
>>
>> I wonder how libbsd.py goes with these rules. Also all the wscript files which
>> are also python and also the RSB would be covered.
>
> Most likely not well. But that's the problem: We already have a bunch of
> different styles. Let's try to agree on one before we get lots of extra
> code. A lot of pre-qualification code will be python. Therefore now is
> the best time.
You may know more than me about this. We have been given no information about
the project's plans or these tools and is becoming frustrating. Joel and I have
asked on a number occasions. The silence is testing our patience.
How about we put a python rules discussion on hold until the intentions of the
pre-qual project are presented publicly and in a manner we can all digest. I
have spent enough time and energy discussing this stuff and it is not clear to
me we are in a position to accept what is to be written.
> If I understood you correctly your main problem with both suggested ones
> (PEP8 and Google) is that multi line lists have been put together into
> one liners and dictionaries with aligned fields are not aligned anymore?
They cannot be touched ...
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/darwin.py#n41
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/freebsd.py#n50
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/linux.py#n54
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/linux.py#n104
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/linux.py#n104
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/options.py#n56
https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n59
https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n108
https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n148
I could go on but I think this list should highlight the issue.
> About correct?
The lack of space around the arguments is also a change that is silly and I do
not want changed.
The biggest challenge who ever finally proposes these rules faces is the RSB. It
is very difficult to know if you have broken it. It has taken years to converge
to the level of stability we have. All changes in here would need a close review
and that something I am not excited about.
Chris
More information about the devel
mailing list