<div dir="ltr">One random thought is how to ensure that patches from people with <div>hardware who submit patches to fix bugs get through the process.</div><div>We have generally trusted people who have hardware. This is common</div><div>for boards none of us have.</div><div><br></div><div>Also we have relied on a timeout rule and a level of significance. Like yesterday</div><div>I committed a one-character fix for an error message in ticker.</div><div><br></div><div>There is also a level of significance where a ticket is required. </div><div><br></div><div>Yes we generally want an independent review but we have generally</div><div>all had a threshold where that's needed.</div><div><br></div><div>--joel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 23, 2019 at 8:30 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 Gedare,<br>
<br>
thanks for the review, here is a second version. The final review can <br>
later when I submit the patch for the RTEMS Software Engineering manual.<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 requirement approvers*: Persons which registered their public <br>
key in<br>
the RTEMS project. They can create approval signatures with their <br>
private<br>
key. Their public key can be used by everyone to verify the approval<br>
signatures.<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>
Reviews and comments may be submitted by anyone, but a maintainer review is<br>
required to approve *significant* changes. In addition, there should be at<br>
least one reviewer with a sufficient independence from the author which<br>
proposes a new requirement or a change of an existing requirement. <br>
Working in<br>
another company on different projects is sufficiently independent. <br>
Patches can<br>
be sent at anytime, so controlling changes in RTEMS requires a permanent<br>
involvement on the RTEMS developer mailing list.<br>
<br>
For a qualification of RTEMS according to certain standards, the <br>
requirements<br>
may be approved by an RTEMS user. 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.<br>
<br>
* Users should be able to register their public key in the RTEMS project to<br>
become an RTEMS requirement approver. The RTEMS maintainer decide <br>
over the<br>
registration.<br>
<br>
* Requirement approvers should be able to attach their approval to<br>
requirements, test procedures, test cases and justification reports.<br>
<br>
* Attaching an approval should be independent of the normal development work<br>
flow, e.g. it should be possible to commit an approval long after<br>
requirements are committed.<br>
<br>
* Please note that disapproval must be done at the time of the initial patch<br>
review. If an approver needs changes in a requirement to approve it, <br>
then<br>
the normal development process must be followed, e.g. the approver <br>
can make a<br>
patch with the change and send it for review to the developer mailing <br>
list.<br>
<br>
* Other users should be able to figure out which part of RTEMS is <br>
approved by<br>
which requirement approver.<br>
<br>
* The integrity of approvals should be ensured by digital signatures (PGP).<br>
<br>
* Changes in RTEMS should invalidate automatically all approvals which are<br>
affected by the change (on a best-effort basis).<br>
<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. The service to manage<br>
approvals can be done with a new Doorstop feature, see<br>
`#375 <<a href="https://github.com/jacebrowning/doorstop/issues/375" rel="noreferrer" target="_blank">https://github.com/jacebrowning/doorstop/issues/375</a>>`_,<br>
<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>