On Mon, Jul 29, 2019 at 11:57 PM Sebastian Huber
wrote:
>
> On 30/07/2019 00:25, Gedare Bloom wrote:
> >> We have to be careful to do what makes them presentable to humans.
> >>
> > It would seem wise to make the hierarchy of requirements follow the
> > same organization as the hierarchy of the Ma
On 30/07/2019 00:25, Gedare Bloom wrote:
We have to be careful to do what makes them presentable to humans.
It would seem wise to make the hierarchy of requirements follow the
same organization as the hierarchy of the Manual documentation.
Yes, and the source code organization. We have also t
On Tue, Jul 23, 2019 at 9:36 AM Joel Sherrill wrote:
>
> Hi
>
> I am not sure if I am derailing this or helping. I think we need to seriously
> consider that we want these to be easy to manage and the logical names
> should reflect the natural groups in RTEMS.
>
> I lean to something simple like t
Hi
I am not sure if I am derailing this or helping. I think we need to
seriously
consider that we want these to be easy to manage and the logical names
should reflect the natural groups in RTEMS.
I lean to something simple like this without the arbitrary sections. ARINC
653
doesn't have odd subse
- Am 22. Jul 2019 um 15:55 schrieb joel j...@rtems.org:
> On Mon, Jul 22, 2019 at 12:53 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello,
>>
>> I would like to clarify one detail with respect to the requirement
>> identifiers. The current consensus is that the requ
On Mon, Jul 22, 2019 at 12:53 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
> I would like to clarify one detail with respect to the requirement
> identifiers. The current consensus is that the requirements should be
> grouped by component, e.g.
>
> RTEMS
> ^-- RTEMS-C
Hello,
I would like to clarify one detail with respect to the requirement
identifiers. The current consensus is that the requirements should be
grouped by component, e.g.
RTEMS
^-- RTEMS-Classic
^-- RTMES-Classic-Task
^-- RTMES-Classic-Semaphore
^-- RTEMS-POSIX
The group name and a n
On 18/07/2019 15:36, Sebastian Huber wrote:
On 11/07/2019 15:44, Sebastian Huber wrote:
On 11/07/2019 15:19, Joel Sherrill wrote:
Early on, we discussed that there wasn't a Rest backend to Doorstop.
If we are having
to add that anyway, can each "category" be generated as a chapter?
We could g
On 11/07/2019 15:44, Sebastian Huber wrote:
On 11/07/2019 15:19, Joel Sherrill wrote:
Early on, we discussed that there wasn't a Rest backend to Doorstop.
If we are having
to add that anyway, can each "category" be generated as a chapter?
We could generate 100+ chapters but we can't have 100+
On 11/07/2019 15:19, Joel Sherrill wrote:
Early on, we discussed that there wasn't a Rest backend to Doorstop. If
we are having
to add that anyway, can each "category" be generated as a chapter?
We could generate 100+ chapters but we can't have 100+ requirements
documents.
We will have custo
Early on, we discussed that there wasn't a Rest backend to Doorstop. If we
are having
to add that anyway, can each "category" be generated as a chapter?
We could generate 100+ chapters but we can't have 100+ requirements
documents.
I lean strongly to needing categories of requirements. It would b
11 matches
Mail list logo
