Hello Andrew, I did not intent to become the authority in numbering files. :-)
Maybe Sebastian has some advice as he knows your application better than I do. I personally would be pragmatic and do what seems to be an easy to realize as well as a good solution. Greetings Frank On 12/11/20 4:30 PM, Andrew Butterfield wrote: > Hello Frank, > > I have a use case where the numbers will exceed 10 . > > It's not for numbered requirements but numbered test-files. > These result from different scenarios generated by our SPIN models, as > part of the qualification activity. > > The files are generated (and numbered) automatically, so the constraints > are somewhat different. > > For the Events Manager, for example, I'd expect the final number of > generated test source files to exceed 10. > It is unlikely that we would reach 100, though. > > Regards, Andrew > >> On 11 Dec 2020, at 15:16, Frank Kühndel >> <frank.kuehn...@embedded-brains.de >> <mailto:frank.kuehn...@embedded-brains.de>> wrote: >> >> Hello Joel, >> >> On 12/11/20 3:49 PM, Joel Sherrill wrote: >>> >>> >>> On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel >>> <frank.kuehn...@embedded-brains.de >>> <mailto:frank.kuehn...@embedded-brains.de> >>> <mailto:frank.kuehn...@embedded-brains.de >>> <mailto:frank.kuehn...@embedded-brains.de>>> wrote: >>> >>> From: Frank Kühndel <frank.kuehn...@embedded-brains.de >>> <mailto:frank.kuehn...@embedded-brains.de> >>> <mailto:frank.kuehn...@embedded-brains.de >>> <mailto:frank.kuehn...@embedded-brains.de>>> >>> >>> --- >>> eng/req/req-for-req.rst | 21 +++++++++++++++++++++ >>> 1 file changed, 21 insertions(+) >>> >>> diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst >>> index 9225e95..dcc4c11 100644 >>> --- a/eng/req/req-for-req.rst >>> +++ b/eng/req/req-for-req.rst >>> @@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname >>> >>> ... >>> >>> +If requirements or the YAML files which contain them are to be >>> numbered, >>> +the numbering shall start with 0. For example: >>> >>> + >>> +.. code-block:: none >>> + >>> + weak-alias-0.yml >>> + weak-alias-1.yml >>> + >>> +Smaller numbers shall be prefixed with 0 to the same count of digits >>> +as the largest number. For example: >>> >>> >>> When one goes from 99 to 100 requirements and didn't anticipate having >>> that many, does this mean all the files will have to be renamed? >> >> I can change the text to what Gedare Bloom suggested: "If we know the >> max count (N) ahead of time, ..." >> >> Just from my experience with the requirements for the basedefs, when I >> create the requirements for an operation, I know the number I end up >> with before checking them in. The issue we discuss would only cause >> trouble if later more requirements for the same operation must be added. >> This is not totally unlikely but it means that one actually has 9 and >> then need a 10th one. >> >>> >>> Should we start with a minimum of three or four digits? What would drive >>> the number of requirements in a set? How large of a functional area will >>> a single numbered set contain? >>> >>> I'm just wondering if it is simpler to just have 001 as a minimum. >> >> I think that 99 requirements for a single operation are really out of >> scope. That will hopefully never ever happen. Even 9 is already a lot. >> Also it is rather advisable to adapt the names of the requirements to >> indicate the purpose. The numbering is more for the case that there are >> two or more requirements on the same topic (like on handling the same >> bad input argument). >> >> my-function-0 >> my-function-1 >> my-function-global-side-effect >> my-function-bad-argument-x-error-handling >> my-function-bad-argument-y-error-handling >> my-function-called-in-wrong-state >> >> My opinion is that defining whether we start counting with 0 or with 1 >> makes sense. Everything else seems to me a bit like solving theoretical >> problems. >> >>> >>> + >>> +.. code-block:: none >>> + >>> + alias-00.yml >>> + alias-01.yml >>> + alias-02.yml >>> + ... >>> + alias-09.yml >>> + alias-10.yml >>> + alias-11.yml >>> + >>> Conflict Free Requirements >>> -------------------------- >>> >>> -- >>> 2.26.2 >>> >>> _______________________________________________ >>> devel mailing list >>> devel@rtems.org <mailto:devel@rtems.org> <mailto:devel@rtems.org >>> <mailto:devel@rtems.org>> >>> http://lists.rtems.org/mailman/listinfo/devel >>> <http://lists.rtems.org/mailman/listinfo/devel> >>> <http://lists.rtems.org/mailman/listinfo/devel >>> <http://lists.rtems.org/mailman/listinfo/devel>> >>> >> >> Greetings >> Frank >> _______________________________________________ >> devel mailing list >> devel@rtems.org <mailto:devel@rtems.org> >> http://lists.rtems.org/mailman/listinfo/devel > > -------------------------------------------------------------------- > Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 > Lero@TCD, Head of Software Foundations & Verification Research Group > School of Computer Science and Statistics, > Room G.39, O'Reilly Institute, Trinity College, University of Dublin > http://www.scss.tcd.ie/Andrew.Butterfield/ > <http://www.scss.tcd.ie/Andrew.Butterfield/> > -------------------------------------------------------------------- > -- embedded brains GmbH Herr Frank KÜHNDEL Dornierstr. 4 82178 Puchheim Germany email: frank.kuehn...@embedded-brains.de phone: +49-89-18 94 741 - 23 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
