On Wed, Dec 5, 2018 at 6:47 PM Chris Johns <chr...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/users >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
