<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 6:47 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/12/2018 17:14, Sebastian Huber wrote:<br>
> On 04/12/2018 17:53, Amaan Cheval wrote:<br>
>> This is great news!<br>
>><br>
>> - Is there a way for other interested parties to join the effort (volunteers<br>
>> from the community)?<br>
> <br>
> Yes, of course, however it will be not easy to coordinate. The development<br>
> should follow the usual RTEMS development workflow, e.g. discussions on the<br>
> mailing list, tickets, patches for review, etc.<br>
<br>
There is a couple of points we need to consider.<br>
<br>
Ideally the qualification effort needs to have a "zero cost" impact on the open<br>
source RTEMS project. The term "zero cost" is fluid in an open source project<br>
and it is an ideal that will be hard to meet but as a goal it is good to have.<br>
There will be some monetary costs and there will be overheads added to the open<br>
source project and how it operates. We will all need to wear two hats, a<br>
qualification one and a community contributor hat.<br>
<br>
As Joel as stated, the qualification process in the RTEMS project needs to<br>
sustain itself. It's life cycle, processes and outcomes needs to run<br>
independently of the RTEMS parts it depends on. Qualification could be viewed as<br>
a specialised deployment of RTEMS. Anyone should be able to take the<br>
qualification processes and use them to create the needed artefacts for<br>
qualification.<br></blockquote><div><br></div><div>From my perspective, the RTEMS Project is taking ownership for technical</div><div>data that may be used in a system qualification based on a safety standard.</div><div>The qualification has to be done against a real system. The standard may</div><div>vary and the target hardware will vary. So the community won't be providing</div><div>direct qualifcation artifacts in my view of this.</div><div><br></div><div>Viewing is as technical data helps me mentally because then I can look at</div><div>each piece of data and evaluate whether this is an improvement to something</div><div>we already have (e.g. Coding Convention docs, coverage reports, etc) or</div><div>something new which has an "absorption and maintenance cost". We just need</div><div>to be careful to evaluate each required technical data input needed. <br></div><div><br></div><div>I think we will have Non-Recurring Engineering to absorb this. Those not</div><div>on this project are not funded to evaluate the submissions or make improvements</div><div>to <a href="http://rtems.org">rtems.org</a> services. That puts a burden on the volunteers. This is a serious</div><div>challenge.</div><div><br></div><div>Once we get past absorption issues, we need to make sure we don't add</div><div>the requirement to use non-free tools or add serious burden for normal patches</div><div>or other submissions. Say someone submits a new BSP or port, it shouldn't</div><div>be harder than it is now. We may have a better defined process but that's OK.<br><br></div><div>Chris and I have had discussions on having a requirements set with full traceability</div><div>to tests and whether than imposes burden. I tend to believe that once created, <br></div><div>the incremental burden will be low (assuming requirement ool issues addressed)</div><div>because RTEMS doesn't change fast from a user view and that's what the requirements</div><div>would reflect, so the requirements wouldn't change much. But we do NOT do this <br></div><div>activity now so there is something else to consider when making a change. Now we</div><div>say you touch code, tests, and documentation. We now say make sure you don't</div><div>need to touch the requirements.</div><div><br></div><div>I want us all to evaluate the impact using at least two user profiles. One is the</div><div>college student who wants to contribute. We have long had simulator BSPs and</div><div>on-boarding help to make this painless and not require special HW. That can't</div><div>change. The other profile is someone making changes. We can't have a process</div><div>that crushes them.<br></div><div><br></div><div>I'm not fearful about this but we must be FULLY aware of absorption and maintenance</div><div>costs/burden and cognizant of getting the work properly reviewed and incorporated.</div><div>Free labor can't be assumed to do enormous heavy lifting for qualification.</div><div><br></div><div>I do expect the community to help review documents describing community processes</div><div>as we refine them.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>> - Will all the work also be planned on public channels (devel@, public WIP<br>
>> branches, etc.)?<br>
> <br>
> The project infrastructure is undecided. We probably need some extra Git<br>
> repositories for WIP stuff. I am not sure if we want to add WIP branches to the<br>
> main RTEMS repositories.<br>
<br>
I would need to see some more detail on what you and others are considering as a<br>
way of working before I can agree to adding branches. Branches are easy to<br>
create, it is what happens to them and when that is the hard part.<br>
<br>
Why not use master?<br></blockquote><div><br></div><div>This needs discussion. If it is improvements to existing things, improve them in public</div><div>as normal. <br></div><div><br></div><div>If it is new, let's discussion how to absorb it and get it into the mainstream ASAP.<br><br></div><div>I agree with Chris, let's have examples.</div><div><br></div><div>FWIW as soon as GCI wraps up, I am going to post the Software Engineering Handbook</div><div>for review. I want it merged. It reflects what was in the Wiki and we need to work through that.</div><div>It fills in some of the required process and standard practice documents required by the</div><div>DO-178, NASA, and ESA quality standards. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Maybe we can host the WIP repositories on <a href="http://rtems.org" rel="noreferrer" target="_blank">rtems.org</a> or Github.<br>
<br>
The RTEMS Project does not support the hosting of active repos on github, we<br>
mirror repos we consider important. We host our repos on <a href="http://git.rtems.org" rel="noreferrer" target="_blank">git.rtems.org</a>. My<br>
concern fragmenting what we have and where users find things.<br></blockquote><div><br></div><div>I don't want to fragment. Let's deal with this on a case by case basis.</div><div><br></div><div>--joel<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
</blockquote></div></div>