<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019 at 1:39 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,<br>
<br>
I work currently on a requirements engineering section for RTEMS in the <br>
RTEMS Software Engineering manual:<br>
<br>
<a href="https://docs.rtems.org/branches/master/eng/index.html" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/eng/index.html</a><br>
<br>
One topic is the Change Control Board (CCB). The Doorstop maintainer was <br>
not so fond of my idea to add support for digital signatures:<br>
<br>
<a href="https://github.com/jacebrowning/doorstop/issues/375" rel="noreferrer" target="_blank">https://github.com/jacebrowning/doorstop/issues/375</a><br>
<br>
So, here is a new proposal without signatures. I think this makes the <br>
process a bit easier.<br>
<br>
Change Control Board<br>
--------------------<br>
<br>
Working with requirements usually involves a Change Control Board<br>
(:term:`CCB`). The CCB of the RTEMS project is the<br>
`RTEMS developer mailing list <br>
<<a href="https://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">https://lists.rtems.org/mailman/listinfo/devel</a>>`_.<br>
<br>
There are the following actors involved:<br>
<br>
* *RTEMS users*: Everyone using the RTEMS real-time operating system to <br>
design,<br>
develop and build an application on top of it.<br>
<br>
* *RTEMS developers*: The persons developing and maintaining RTEMS. <br>
They write<br>
patches to add or modify code, requirements, tests and documentation.<br>
<br>
* *RTEMS maintainers*: They are listed in the<br>
`MAINTAINERS <<a href="https://git.rtems.org/rtems/tree/MAINTAINERS" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/MAINTAINERS</a>>`_ file <br>
and have<br>
write access to the project repositories.<br>
<br>
.. TODO: Make a reference to the "normal patch review process".<br>
<br>
Adding and changing requirements follows the normal patch review process.<br></blockquote><div><br></div><div>The normal process should be defined and referenced.</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">
Reviews and comments may be submitted by anyone, but a maintainer review is<br>
required to approve *significant* changes. In addition for significant<br>
changes, there should be at least one reviewer with a sufficient <br>
independence<br>
from the author which proposes a new requirement or a change of an existing<br>
requirement. Working in another company on different projects is <br>
sufficiently<br>
independent. </blockquote><div><br></div><div>Different companies and same funding source isn't independent.</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"> RTEMS maintainers do not know all the details, so they <br>
trust in<br>
general people with experience on a certain platform. Sometimes no review<br>
comments may appear in a reasonable time frame, then an implicit <br>
agreement to<br>
the proposed changes is assumed. Patches can be sent at anytime, so<br>
controlling changes in RTEMS requires a permanent involvement on the RTEMS<br>
developer mailing list.<br></blockquote><div><br></div><div>There is a problem with independence and reasonable time frame. You are</div><div>relying on volunteers to review requirements (or anything else) and at their time<br>availability mercy. I don't know how you ensure you have proper second reviewers</div><div>from the volunteer community in a reasonable time frame. Lack of commentary</div><div>could just mean personal issues or travel. For example, I spent 3 weeks of June</div><div>traveling and/or teaching and was sick enough for two rounds of antibiotics. I</div><div>care about reviewing but I didn't review much last month. And even when I do</div><div>review, there is a practical limit.</div><div><br></div><div>Some of this going to have to be spoon fed to the community to have a chance</div><div>to get it reviewed by volunteer. Better would be paid time from alternative core </div><div>developers to speed this up.But ultimately some core reviewers will be volunteer</div><div>and slow.</div><div><br></div><div>A normal timeout isn't appropriate for requirements. They really deserve positive</div><div>acknowledge. A true CCB waits for a majority from a quorum.</div><div><br></div><div>A technical part of the solution is be something like Phabricator which tracks</div><div>getting multiple approvals and lets you do online reviews. A tool like this also</div><div>helps with the records for code reviews and approval beyond the final git log.</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>
For a qualification of RTEMS according to certain standards, the <br>
requirements<br>
may be approved by an RTEMS user. </blockquote><div><br></div><div>I think you mean tailoring the requirements and code.</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">The approval by RTEMS users is not the<br>
concern of the RTEMS project, however, the RTEMS project should enable RTEMS<br>
users to manage the approval of requirements easily. This information <br>
may be<br>
also used by a independent authority which comes into play with an <br>
Independent<br>
Software Verification and Validation (:term:`ISVV`). It could be used to<br>
select a subset of requirements, e.g. look only at the ones approved by a<br>
certain user. </blockquote><div><br></div><div>Careful with approved. Do you mean tailoring again?</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"> RTEMS users should be able to reference the determinative<br>
content of requirements, test procedures, test cases and justification <br>
reports<br>
in their own documentation. Changes in the determinative content should<br>
invalidate all references to previous versions.<br></blockquote><div><br></div><div>Determinative doesn't appear to be a word. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
.. topic:: Doorstop<br>
<br>
In Doorstop some values of an item (generalization of a requirement)<br>
contribute to a<br>
`fingerprint of the item <br>
<<a href="https://github.com/jacebrowning/doorstop/blob/develop/docs/reference/items.md#reviewed" rel="noreferrer" target="_blank">https://github.com/jacebrowning/doorstop/blob/develop/docs/reference/items.md#reviewed</a>>`_.<br>
Changing a value, e.g. the text of a requirement, changes the <br>
fingerprint.<br>
The links from one item to another include the fingerprint, so the <br>
impact<br>
of changes is also visible to dependent items. Currently, MD5 is <br>
used as<br>
the hash. Since this hash is insecure, it is proposed to add a<br>
configuration option to Doorstop which enables SHA512 for hashes.<br>
<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>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>