<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 3:43 AM <<a href="mailto:Jan.Sommer@dlr.de">Jan.Sommer@dlr.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would like this idea.<br>
We got Gitlab this year and collaboration with it is pretty convenient.<br>
They also seem to hand out free licenses for OSS projects.<br>
I guess installing and maintaining an instance is probably quite some work.<br></blockquote><div><br></div><div>We use Gitlab community edition internally. On a recent non-RTEMS project, </div><div>we pushed the Continuous Integration and Testing pretty hard. We built, </div><div>tested, and did coverage for 4 configurations of the software for 3 different </div><div>Linux distributions using Docker on every push. We built Doxygen every time</div><div>and ran the FACE Conformance Test Suite on multiple components. Plus </div><div>had a  commercial tool that did MISRA/CERT compliance checking and MCDC</div><div>coverage analysis. Everything ran well but the commercial tool took a </div><div>fair amount of babying. </div><div><br></div><div>We didn't use it for patch management though. We just required issues</div><div>and you had to pass the CIT to merge. We did use milestones for light</div><div>project management but only the basics of the ticketing system.</div><div><br></div><div>One challenge RTEMS has with automated testing is the turnaround time. </div><div>On the project I mentioned, everything took only a few minutes except the </div><div>commercial tool which ended up taking 30 minutes. For RTEMS, building </div><div>and testing everything is quite time consuming. The script I run takes about </div><div>1 day on an 8 core Xeon and ~2.5 days on the older quad-cores. I don't test </div><div>anything on hardware in that cycle. Because of this, the testing part of CIT</div><div>for RTEMS will likely always only be spot checking. But we could put more </div><div>emphasis on say Doxygen builds always being warning free and the critical </div><div>BSPs that are spot checked being warning free.  </div><div><br></div><div>The "critical set of BSPs" to be spot checked is up for discussion but </div><div>ideally they would run on simulators and represent a realistic but broad </div><div>subset. That makes the long version of the list something like sparc/leon3, </div><div>arm/zynq_qemu, x86/pc, powerpc/psim and mips/jmr3904. </div><div><br></div><div>This was a long reply to just cover what I think we could do for CIT on</div><div>the RTEMS repo. Considering rtems-docs, examples, etc. adds other </div><div>options.</div><div><br></div><div>Back to the patch management system.....</div><div><br></div><div>We have discussed having Patchwork and Phabricator in the past. I don't</div><div>know if there is a true resistance to using such a tool but a lack of time.</div><div>All system administration on <a href="http://rtems.org">rtems.org</a> is volunteer.  That by itself is the</div><div>biggest barrier. </div><div><br></div><div>--joel</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Ph<br>
Best regards,<br>
<br>
   Jan<br>
<br>
> -----Original Message-----<br>
> From: devel <<a href="mailto:devel-bounces@rtems.org" target="_blank">devel-bounces@rtems.org</a>> On Behalf Of Christian Mauderer<br>
> Sent: Wednesday, September 9, 2020 10:24 AM<br>
> To: RTEMS Devel RTEMS <<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
> Subject: We are loosing patches<br>
> <br>
> Hello,<br>
> <br>
> triggered by a comment from Chris here<br>
> <br>
>     <a href="https://lists.rtems.org/pipermail/users/2020-September/067873.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/users/2020-September/067873.html</a><br>
> <br>
> I started to take a look at patches from non maintainers and write after<br>
> approval maintainers for some months: I think in May and June we lost at<br>
> least one or two of the following ones:<br>
> <br>
> <a href="https://lists.rtems.org/pipermail/devel/2020-May/059751.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-May/059751.html</a><br>
> <a href="https://lists.rtems.org/pipermail/devel/2020-May/059771.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-May/059771.html</a><br>
> <a href="https://lists.rtems.org/pipermail/devel/2020-May/059772.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-May/059772.html</a><br>
> <a href="https://lists.rtems.org/pipermail/devel/2020-May/059773.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-May/059773.html</a><br>
> <a href="https://lists.rtems.org/pipermail/devel/2020-June/060125.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-June/060125.html</a><br>
> <a href="https://lists.rtems.org/pipermail/devel/2020-June/060231.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-June/060231.html</a><br>
> <a href="https://lists.rtems.org/pipermail/devel/2020-June/060235.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-June/060235.html</a><br>
> <br>
> It's a bit hard to see exactly whether a later version has been added with a<br>
> different subject, merged with another patch or just has been rejected for<br>
> some reason. That's another problem with our current system.<br>
> <br>
> I think we start to loose valuable contributions due to that. I also found some<br>
> patches where just no one responded because no one noted it and the<br>
> person sending the patch had to ping it some time later. That's not really<br>
> encouraging to continue participating for new contributors.<br>
> <br>
> I even lost track of some of my own patches in the past and found out about<br>
> a month later that I should have pushed them long ago.<br>
> <br>
> Maybe it would be a good idea to start at least discussing whether we should<br>
> change something to avoid these problems. I think our current system has<br>
> two main problems:<br>
> <br>
> 1. All patches go to one single devel mailing list. It's sometimes hard to see<br>
> which patches are for what repository. And small patches tend to just vanish<br>
> between lot of other mails.<br>
> <br>
> 2. We have a big problem seeing which patch sets are done, which are in the<br>
> middle of a discussion and which are rejected.<br>
> <br>
> A lot of other projects use software to solve these problems. Linux uses<br>
> "patchwork" for it since a long time (which needs one mailing list per<br>
> project). Most other projects use systems with pull requests like github or a<br>
> self hosted gitlab for that kind of stuff.<br>
> <br>
> Maybe we should think about following these examples and go one step to<br>
> more modern software development too? What do you think?<br>
> <br>
> Best regards<br>
> <br>
> Christian<br>
> --<br>
> --------------------------------------------<br>
> embedded brains GmbH<br>
> Herr Christian Mauderer<br>
> Dornierstr. 4<br>
> D-82178 Puchheim<br>
> Germany<br>
> email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
> Phone: +49-89-18 94 741 - 18<br>
> Fax:   +49-89-18 94 741 - 08<br>
> PGP: Public key available on request.<br>
> <br>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>