Qualification of RTEMS SMP (ECSS)

Thu Dec 6 16:36:45 UTC 2018

On Wed, Dec 5, 2018 at 6:47 PM Chris Johns <chrisj at rtems.org> wrote:

> On 05/12/2018 17:14, Sebastian Huber wrote:
> > On 04/12/2018 17:53, Amaan Cheval wrote:
> >> This is great news!
> >>
> >> - Is there a way for other interested parties to join the effort
> (volunteers
> >> from the community)?
> >
> > Yes, of course, however it will be not easy to coordinate. The
> development
> > should follow the usual RTEMS development workflow, e.g. discussions on
> the
> > mailing list, tickets, patches for review, etc.
>
> There is a couple of points we need to consider.
>
> Ideally the qualification effort needs to have a "zero cost" impact on the
> open
> source RTEMS project. The term "zero cost" is fluid in an open source
> project
> and it is an ideal that will be hard to meet but as a goal it is good to
> have.
> There will be some monetary costs and there will be overheads added to the
> open
> source project and how it operates. We will all need to wear two hats, a
> qualification one and a community contributor hat.
>
> As Joel as stated, the qualification process in the RTEMS project needs to
> sustain itself. It's life cycle, processes and outcomes needs to run
> independently of the RTEMS parts it depends on. Qualification could be
> viewed as
> a specialised deployment of RTEMS. Anyone should be able to take the
> qualification processes and use them to create the needed artefacts for
> qualification.
>

>From my perspective, the RTEMS Project is taking ownership for technical
data that may be used in a system qualification based on a safety standard.
The qualification has to be done against a real system. The standard may
vary and the target hardware will vary. So the community won't be providing
direct qualifcation artifacts in my view of this.

Viewing is as technical data helps me mentally because then I can look at
each piece of data and evaluate whether this is an improvement to something
we already have (e.g. Coding Convention docs, coverage reports, etc) or
something new which has an "absorption and maintenance cost". We just need
to be careful to evaluate each required technical data input needed.

I think we will have Non-Recurring Engineering to absorb this. Those not
on this project are not funded to evaluate the submissions or make
improvements
to rtems.org services. That puts a burden on the volunteers. This is a
serious
challenge.

Once we get past absorption issues, we need to make sure we don't add
the requirement to use non-free tools or add serious burden for normal
patches
or other submissions. Say someone submits a new BSP or port, it shouldn't
be harder than it is now. We may have a better defined process but that's
OK.

Chris and I have had discussions on having a requirements set with full
traceability
to tests and whether than imposes burden. I tend to believe that once
created,
the incremental burden will be low (assuming requirement ool issues
addressed)
because RTEMS doesn't change fast from a user view and that's what the
requirements
would reflect, so the requirements wouldn't change much. But we do NOT do
this
activity now so there is something else to consider when making a change.
Now we
say you touch code, tests, and documentation. We now say make sure you don't
need to touch the requirements.

I want us all to evaluate the impact using at least two user profiles. One
is the
college student who wants to contribute. We have long had simulator BSPs and
on-boarding help to make this painless and not require special HW. That
can't
change. The other profile is someone making changes. We can't have a process
that crushes them.

I'm not fearful about this but we must be FULLY aware of absorption and
maintenance
costs/burden and cognizant of getting the work properly reviewed and
incorporated.
Free labor can't be assumed to do enormous heavy lifting for qualification.

I do expect the community to help review documents describing community
processes
as we refine them.

>
> >> - 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.
>
> Why not use master?
>

This needs discussion. If it is improvements to existing things, improve
them in public
as normal.

If it is new, let's discussion how to absorb it and get it into the
mainstream ASAP.

I agree with Chris, let's have examples.

FWIW as soon as GCI wraps up, I am going to post the Software Engineering
Handbook
for review. I want it merged. It reflects what was in the Wiki and we need
to work through that.
It fills in some of the required process and standard practice documents
required by the
DO-178, NASA, and ESA quality standards.

>
> > 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.
>

I don't want to fragment. Let's deal with this on a case by case basis.

--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/20181206/be98b360/attachment-0002.html>