<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Dec 9, 2018 at 5:22 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 08/12/2018 00:45, Sebastian Huber wrote:<br>
> On 06/12/2018 01:47, Chris Johns wrote:<br>
>>>> - Will all the work also be planned on public channels (devel@, public WIP<br>
>>>> branches, etc.)?<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>
>> 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>
> I don't think project-specific branches in the main repositories are a good<br>
> idea.<br>
<br>
I agree.<br>
<br>
> I think the private repositories we used for example during the make<br>
> preinstall elimination are better for work in progress stuff.<br>
<br>
I am happy with developer repo's being used.<br>
<br>
>><br>
>> Why not use master?<br>
> <br>
> For the RTEMS sources we can use the master. For other parts, e.g. things that<br>
> may go into rtems-tools or whatever, which are newly developed I think it is<br>
> beneficial if some project internal review happens first before it is presented<br>
> to the overall RTEMS community.<br>
<br>
Yes this is fine. The rtems-tools project is now an important part of the RTEMS<br>
eco-system and I agree we need to handle what happens with it in a more formal<br>
manner.<br>
<br>
I added Python unit tests recently with the `./waf test` command. Most of the<br>
python unit tests are easy to implement, extend and run while some are more<br>
complicated like sending an email. The linker tests are harder because of the<br>
dependence on a built BSP for ELF object files unless we add some object files<br>
to the repo, something I am not sure about. I am currently uses some RTEMS<br>
kernel tests as a way of testing some of these commands.<br>
<br>
> Everyone interested should still have the opportunity to look at it.<br>
<br>
This is fine if we assume those who can review the changes are able too. The<br>
qual effort and those driving this need to understand what this means and manage it.<br>
<br>
>>> Maybe we can host the WIP repositories on <a href="http://rtems.org" rel="noreferrer" target="_blank">rtems.org</a> or Github.<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>
> <br>
> Yes, this is a valid issue. Google finds all sorts of RTEMS repositories for<br>
> example.<br>
<br>
My only answer is to say the <a href="http://rtems.org" rel="noreferrer" target="_blank">rtems.org</a> based repositories are the upstream masters.<br></blockquote><div><br></div><div>I agree with everything. It is in everyone's best long term interest to follow our normal</div><div>processes and push everything to be public and evaluated incrementally.</div><div><br></div><div>I just hope the subtly of me saying I want "technical data" to</div><div>be owned by the RTEMS Project and the impact of "owning it" considered before it</div><div>is merged. Some items will be improvements and possibly no recurring engineering,</div><div>others will be improvements with some recurring engineering (aka maintenance burden),</div><div>while others will be new and burden will have to be evaluated. I just want us to be open</div><div>to accepting everything but with a serious look for burden. It is the responsibility of</div><div>those interested in qualification to help push us past the NRE and reduce the burden.<br><br>My use of the term "technical data" is to be distinct from "qualification artifacts". The former</div><div>is in a generic, quality standard independent format. The latter is specific to a safety </div><div>standard. For example, helping you know the interrupt latency or memory consumption</div><div>is technical data as is requirements. Putting those in a non-neutral document is another.</div><div>I expect a transformation process to take the technical data and produce reports. </div><div><br></div><div>--joel</div><div><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>