Qualification of RTEMS SMP (ECSS)

[Joel Sherrill]

On Sun, Dec 9, 2018 at 5:22 PM Chris Johns <chrisj at rtems.org> wrote:

> On 08/12/2018 00:45, Sebastian Huber wrote:
> > On 06/12/2018 01:47, Chris Johns wrote:
> >>>> - Will all the work also be planned on public channels (devel@,
> public WIP
> >>>> branches, etc.)?
> >>> The project infrastructure is undecided. We probably need some extra
> Git
> >>> repositories for WIP stuff. I am not sure if we want to add WIP
> branches to the
> >>> main RTEMS repositories.
> >> I would need to see some more detail on what you and others are
> considering as a
> >> way of working before I can agree to adding branches. Branches are easy
> to
> >> create, it is what happens to them and when that is the hard part.
> >
> > I don't think project-specific branches in the main repositories are a
> good
> > idea.
>
> I agree.
>
> > I think the private repositories we used for example during the make
> > preinstall elimination are better for work in progress stuff.
>
> I am happy with developer repo's being used.
>
> >>
> >> Why not use master?
> >
> > For the RTEMS sources we can use the master. For other parts, e.g.
> things that
> > may go into rtems-tools or whatever, which are newly developed I think
> it is
> > beneficial if some project internal review happens first before it is
> presented
> > to the overall RTEMS community.
>
> Yes this is fine. The rtems-tools project is now an important part of the
> RTEMS
> eco-system and I agree we need to handle what happens with it in a more
> formal
> manner.
>
> I added Python unit tests recently with the `./waf test` command. Most of
> the
> python unit tests are easy to implement, extend and run while some are more
> complicated like sending an email. The linker tests are harder because of
> the
> dependence on a built BSP for ELF object files unless we add some object
> files
> to the repo, something I am not sure about. I am currently uses some RTEMS
> kernel tests as a way of testing some of these commands.
>
> > Everyone interested should still have the opportunity to look at it.
>
> This is fine if we assume those who can review the changes are able too.
> The
> qual effort and those driving this need to understand what this means and
> manage it.
>
> >>> Maybe we can host the WIP repositories on rtems.org or Github.
> >> The RTEMS Project does not support the hosting of active repos on
> github, we
> >> mirror repos we consider important. We host our repos on git.rtems.org.
> My
> >> concern fragmenting what we have and where users find things.
> >
> > Yes, this is a valid issue. Google finds all sorts of RTEMS repositories
> for
> > example.
>
> My only answer is to say the rtems.org based repositories are the
> upstream masters.
>

I agree with everything. It is in everyone's best long term interest to
follow our normal
processes and push everything to be public and evaluated incrementally.

I just hope the subtly of me saying I want "technical data" to
be owned by the RTEMS Project and the impact of "owning it" considered
before it
is merged. Some items will be improvements and possibly no recurring
engineering,
others will be improvements with some recurring engineering (aka
maintenance burden),
while others will be new and burden will have to be evaluated. I just want
us to be open
to accepting everything but with a serious look for burden. It is the
responsibility of
those interested in qualification to help push us past the NRE and reduce
the burden.

My use of the term "technical data" is to be distinct from "qualification
artifacts". The former
is in a generic, quality standard independent format. The latter is
specific to a safety
standard. For example, helping you know the interrupt latency or memory
consumption
is technical data as is requirements. Putting those in a non-neutral
document is another.
I expect a transformation process to take the technical data and produce
reports.

--joel


> Chris
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20181209/b86b1309/attachment-0002.html>