Re: [docs] eng: Use a recommendation for requirement texts
I understand this change. I wonder if there are some terms that you definitely want to avoid though? Do you have tooling to warn on the use of these terms in requirements? If not, that could be something easy for a student to put together as a beginner/janitor task. On Tue, Jan 17, 2023 at 8:38 AM Sebastian Huber wrote: > > Update #3715. > --- > eng/req/items.rst | 126 +++--- > 1 file changed, 63 insertions(+), 63 deletions(-) > > diff --git a/eng/req/items.rst b/eng/req/items.rst > index 95531a8..19e8726 100644 > --- a/eng/req/items.rst > +++ b/eng/req/items.rst > @@ -4597,130 +4597,130 @@ of links. > Requirement Text > > > -The value shall be a string. It shall state a requirement or constraint. The > -value shall not contain an element of > +The value shall be a string. It shall state a requirement or constraint. The > +text should not use one of the following words or phrases: > > -* "``acceptable``", > +* acceptable > > -* "``adequate``", > +* adequate > > -* "``almost always``", > +* almost always > > -* "``and/or``", > +* and/or > > -* "``appropriate``", > +* appropriate > > -* "``approximately``", > +* approximately > > -* "``as far as possible``", > +* as far as possible > > -* "``as much as practicable``", > +* as much as practicable > > -* "``best``", > +* best > > -* "``best possible``", > +* best possible > > -* "``easy``", > +* easy > > -* "``efficient``", > +* efficient > > -* "``e.g.``", > +* e.g. > > -* "``enable``", > +* enable > > -* "``enough``", > +* enough > > -* "``etc.``", > +* etc. > > -* "``few``", > +* few > > -* "``first rate``", > +* first rate > > -* "``flexible``", > +* flexible > > -* "``generally``", > +* generally > > -* "``goal``", > +* goal > > -* "``graceful``", > +* graceful > > -* "``great``", > +* great > > -* "``greatest``", > +* greatest > > -* "``ideally``", > +* ideally > > -* "``i.e.``", > +* i.e. > > -* "``if possible``", > +* if possible > > -* "``in most cases``", > +* in most cases > > -* "``large``", > +* large > > -* "``many``", > +* many > > -* "``maximize``", > +* maximize > > -* "``minimize``", > +* minimize > > -* "``most``", > +* most > > -* "``multiple``", > +* multiple > > -* "``necessary``", > +* necessary > > -* "``numerous``", > +* numerous > > -* "``optimize``", > +* optimize > > -* "``ought to``", > +* ought to > > -* "``probably``", > +* probably > > -* "``quick``", > +* quick > > -* "``rapid``", > +* rapid > > -* "``reasonably``", > +* reasonably > > -* "``relevant``", > +* relevant > > -* "``robust``", > +* robust > > -* "``satisfactory``", > +* satisfactory > > -* "``several``", > +* several > > -* "``shall be included but not limited to``", > +* shall be included but not limited to > > -* "``simple``", > +* simple > > -* "``small``", > +* small > > -* "``some``", > +* some > > -* "``state of the art``", > +* state of the art > > -* "``sufficient``", > +* sufficient > > -* "``suitable``", > +* suitable > > -* "``support``", > +* support > > -* "``systematically``", > +* systematically > > -* "``transparent``", > +* transparent > > -* "``typical``", > +* typical > > -* "``user friendly``", > +* user friendly > > -* "``usually``", > +* usually > > -* "``versatile``", and > +* versatile > > -* "``when necessary``". > +* when necessary > > This type is used by the following types: > > -- > 2.35.3 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 1/1] RSB: Mitigate too short error reports
OK to push.
Thanks
Chris
On 21/1/2023 2:06 am, Frank Kuehndel wrote:
> From: Frank Kühndel
>
> Close #4642
> ---
> source-builder/sb/ereport.py | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/source-builder/sb/ereport.py b/source-builder/sb/ereport.py
> index d8fb5f6..52ee2eb 100755
> --- a/source-builder/sb/ereport.py
> +++ b/source-builder/sb/ereport.py
> @@ -54,7 +54,9 @@ def generate(name, opts, header = None, footer = None):
> name = name.replace('/', '-')
> with open(name, 'w') as l:
> l.write(os.linesep.join(r))
> -log.notice(' See error report: %s' % (name))
> +log.notice(os.linesep.join([' See error report: %s' % (name),
> +' Note: In some cases the error appears only in',
> +' the complete build log (see --log option)']))
> except:
> log.stderr('error: failure to create error report')
> raise
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Update PyYAML to 5.4.1
On Thu, Jan 19, 2023 at 11:27 PM Sebastian Huber wrote: > > On 20.01.23 03:59, Chris Johns wrote: > > On 20/1/2023 1:51 pm, Gedare Bloom wrote: > >> On Thu, Jan 19, 2023 at 5:23 PM Chris Johns wrote: > >>> On 20/1/2023 2:19 am, Sebastian Huber wrote: > The latest version is 6.0 which dropped support for Python 2.7. > >>> Was 6 our last version to support python 2 and 3? > >>> > >>> Is making this change this close to a release wise? > >>> > >> I sense confusion here. Are we referring to Pyyaml 6.0, or RTEMS 6.0? > > I assumed it referenced RTEMS 6. > > > >> I understand the comment above to mean we can't update to pyyaml 6.0 > >> yet, because it doesn't support Python 2.7 which we still require for > >> the user-facing tools. > > Thanks, that confirms my understanding. So this means it is not OK to apply. > > What is the problem with updating PyYAML to 5.4.1? This version still > supports Python 2.7. > No problem. Chris got confused (twice). This patch looks good. > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > 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
[PATCH v2 1/1] RSB: Mitigate too short error reports
From: Frank Kühndel
Close #4642
---
source-builder/sb/ereport.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/source-builder/sb/ereport.py b/source-builder/sb/ereport.py
index d8fb5f6..52ee2eb 100755
--- a/source-builder/sb/ereport.py
+++ b/source-builder/sb/ereport.py
@@ -54,7 +54,9 @@ def generate(name, opts, header = None, footer = None):
name = name.replace('/', '-')
with open(name, 'w') as l:
l.write(os.linesep.join(r))
-log.notice(' See error report: %s' % (name))
+log.notice(os.linesep.join([' See error report: %s' % (name),
+' Note: In some cases the error appears only in',
+' the complete build log (see --log option)']))
except:
log.stderr('error: failure to create error report')
raise
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 0/1] RSB: Mitigate too short error reports
From: Frank Kühndel Hello, this is the promised patch to close my bug report #4642 https://devel.rtems.org/ticket/4642 "RSB: log.py tends to remove relevant error messages". I tested it using Christian's Github CI - see his Email: https://lists.rtems.org/pipermail/devel/2023-January/074099.html You can see the automated build and test results of the "draft" pull request for this patch here: https://github.com/embedded-brains/rtems-source-builder/pull/4/checks If you have a Github account (needed to see the details and artifacts), you can see the new error report message at the end of the output of failing builds, as for example here (click on the red-bubble at "build toolchain" and scroll to the bottom): https://github.com/embedded-brains/rtems-source-builder/actions/runs/3968465295/jobs/6801666558 Greetings Frank Frank Kühndel (1): RSB: Mitigate too short error reports source-builder/sb/ereport.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add Formal Verification chapter v2
> On 25/11/2022 07:46, Sebastian Huber > wrote: >> On 24/11/2022 14:41, andrew.butterfi...@scss.tcd.ie wrote: >>> On 16/11/2022 16:44, Gedare Bloom wrote: >>>Section 9.7 "RTEMS Formal Model Guide" seems like it includes both >>>some aspects of a How-To but also a lot of details that might be >>>better as a separate document specific to the Promela/Verification >>>detailed implementation. The point of the RTEMS Software Engineering >>>manual is to provide developers with the guidelines of how to work >>>with RTEMS. This section is very detailed about the implementation of >>>specific models and feels unbalanced with the rest of the new section. >>>For example, this section is about 3/5 of the entire "Formal >>>Verification" section. >> >> I agree - this was what struck me after I had sent the patch set. In a >> sense I think we need a new top-level document, analagous to the Classic >> API and POSIX API guides. > > I am not sure if a new top-level document is really the best option. > From my point of view, the RTEMS Software Engineering manual should > cover everything useful for the general RTEMS maintainer. The models > cover core services of RTEMS. With different documents you just have to > open more documents and cross referencing will be more difficult. I am > more in favour of a top-level chapter in the manual or some sort of an > appendix chapter. Now that the integration of the formal models and tools is in progress, I want to revisit this issue. Yes, the models cover core services, but those are described in other documents like the Classic API guide (and POSIX). It would seem that a better place to put any model documentation would be in those guides. However, the formal verification/qualification is something very new, and I’m not sure how regular users would feel about that kind of extra material, at least at this early stage of adopting qual/FV techniques. For now, I am going fixup all the other issues raised by Gedare, and submit a v2 patch set. Regards, Andrew 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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
