We are loosing patches

Wed Sep 9 13:19:42 UTC 2020

On Wed, Sep 9, 2020 at 3:43 AM <Jan.Sommer at dlr.de> wrote:

> I would like this idea.
> We got Gitlab this year and collaboration with it is pretty convenient.
> They also seem to hand out free licenses for OSS projects.
> I guess installing and maintaining an instance is probably quite some work.
>

We use Gitlab community edition internally. On a recent non-RTEMS project,
we pushed the Continuous Integration and Testing pretty hard. We built,
tested, and did coverage for 4 configurations of the software for 3
different
Linux distributions using Docker on every push. We built Doxygen every time
and ran the FACE Conformance Test Suite on multiple components. Plus
had a  commercial tool that did MISRA/CERT compliance checking and MCDC
coverage analysis. Everything ran well but the commercial tool took a
fair amount of babying.

We didn't use it for patch management though. We just required issues
and you had to pass the CIT to merge. We did use milestones for light
project management but only the basics of the ticketing system.

One challenge RTEMS has with automated testing is the turnaround time.
On the project I mentioned, everything took only a few minutes except the
commercial tool which ended up taking 30 minutes. For RTEMS, building
and testing everything is quite time consuming. The script I run takes
about
1 day on an 8 core Xeon and ~2.5 days on the older quad-cores. I don't test
anything on hardware in that cycle. Because of this, the testing part of CIT
for RTEMS will likely always only be spot checking. But we could put more
emphasis on say Doxygen builds always being warning free and the critical
BSPs that are spot checked being warning free.

The "critical set of BSPs" to be spot checked is up for discussion but
ideally they would run on simulators and represent a realistic but broad
subset. That makes the long version of the list something like sparc/leon3,
arm/zynq_qemu, x86/pc, powerpc/psim and mips/jmr3904.

This was a long reply to just cover what I think we could do for CIT on
the RTEMS repo. Considering rtems-docs, examples, etc. adds other
options.

Back to the patch management system.....

We have discussed having Patchwork and Phabricator in the past. I don't
know if there is a true resistance to using such a tool but a lack of time.
All system administration on rtems.org is volunteer.  That by itself is the
biggest barrier.

--joel

Ph
> Best regards,
>
>    Jan
>
> > -----Original Message-----
> > From: devel <devel-bounces at rtems.org> On Behalf Of Christian Mauderer
> > Sent: Wednesday, September 9, 2020 10:24 AM
> > To: RTEMS Devel RTEMS <devel at rtems.org>
> > Subject: We are loosing patches
> >
> > Hello,
> >
> > triggered by a comment from Chris here
> >
> >     https://lists.rtems.org/pipermail/users/2020-September/067873.html
> >
> > I started to take a look at patches from non maintainers and write after
> > approval maintainers for some months: I think in May and June we lost at
> > least one or two of the following ones:
> >
> > https://lists.rtems.org/pipermail/devel/2020-May/059751.html
> > https://lists.rtems.org/pipermail/devel/2020-May/059771.html
> > https://lists.rtems.org/pipermail/devel/2020-May/059772.html
> > https://lists.rtems.org/pipermail/devel/2020-May/059773.html
> > https://lists.rtems.org/pipermail/devel/2020-June/060125.html
> > https://lists.rtems.org/pipermail/devel/2020-June/060231.html
> > https://lists.rtems.org/pipermail/devel/2020-June/060235.html
> >
> > It's a bit hard to see exactly whether a later version has been added
> with a
> > different subject, merged with another patch or just has been rejected
> for
> > some reason. That's another problem with our current system.
> >
> > I think we start to loose valuable contributions due to that. I also
> found some
> > patches where just no one responded because no one noted it and the
> > person sending the patch had to ping it some time later. That's not
> really
> > encouraging to continue participating for new contributors.
> >
> > I even lost track of some of my own patches in the past and found out
> about
> > a month later that I should have pushed them long ago.
> >
> > Maybe it would be a good idea to start at least discussing whether we
> should
> > change something to avoid these problems. I think our current system has
> > two main problems:
> >
> > 1. All patches go to one single devel mailing list. It's sometimes hard
> to see
> > which patches are for what repository. And small patches tend to just
> vanish
> > between lot of other mails.
> >
> > 2. We have a big problem seeing which patch sets are done, which are in
> the
> > middle of a discussion and which are rejected.
> >
> > A lot of other projects use software to solve these problems. Linux uses
> > "patchwork" for it since a long time (which needs one mailing list per
> > project). Most other projects use systems with pull requests like github
> or a
> > self hosted gitlab for that kind of stuff.
> >
> > Maybe we should think about following these examples and go one step to
> > more modern software development too? What do you think?
> >
> > Best regards
> >
> > Christian
> > --
> > --------------------------------------------
> > embedded brains GmbH
> > Herr Christian Mauderer
> > Dornierstr. 4
> > D-82178 Puchheim
> > Germany
> > email: christian.mauderer at embedded-brains.de
> > Phone: +49-89-18 94 741 - 18
> > Fax:   +49-89-18 94 741 - 08
> > PGP: Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200909/69fd3ae9/attachment.html>