We are loosing patches

Christian Mauderer christian.mauderer at embedded-brains.de
Wed Sep 9 14:15:53 UTC 2020 

Hello Jan and Joel,

On 09/09/2020 15:19, Joel Sherrill wrote:
> 
> 
> On Wed, Sep 9, 2020 at 3:43 AM <Jan.Sommer at dlr.de
> <mailto: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.

Also I agree that automated builds or checks could be an extension, that
is not really the core point. Part of these automated builds are already
done by buildbot.rtems.org.

> 
> Back to the patch management system.....

That's the part that (at the moment) was the starting point of my mail.

> 
> 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 <http://rtems.org> is volunteer. 
> That by itself is the
> biggest barrier. 

Regarding the administrative effort: I'm well aware that there is a lot
of work. And if my request adds additional workload, we should discuss
who can do that or how it can be funded. But I don't think that it is a
good situation that patches get lost or that _new_ contributors have to
ping a mail because no one has seen it between lot's of other mails.
Patches are valuable and they are the entry point for every new member
of our community.

Beneath that: Our time is valuable too. If systems can collect all
relevant information for one patch set (including earlier versions,
comments, ...): Why do we waste so much time with searching that kind of
stuff on the mailing list. If you just have to use a single command to
apply the latest version of a patch set: Why do we have to find and
download the patches from the mailing list, apply them locally to the
correct repo, make sure that we did the right thing and then push them.

So please let's not jump right into the administrative part of the
system or how many work it maybe would be to implement it. Let's first
find out whether a big part of our community could agree to a more
modern approach of handling patches that can save time for contributors
and maintainers. As soon as we have one: Let's talk about what is
necessary to reach that solution. If it is a step forward, I'm sure we
will find a solution to handle the initial effort.

Best regards

Christian

> 
> --joel
> 
>     Ph
>     Best regards,
> 
>        Jan
> 
>     > -----Original Message-----
>     > From: devel <devel-bounces at rtems.org
>     <mailto: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 <mailto: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
>     <mailto: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 <mailto:devel at rtems.org>
>     > http://lists.rtems.org/mailman/listinfo/devel
>     _______________________________________________
>     devel mailing list
>     devel at rtems.org <mailto:devel at rtems.org>
>     http://lists.rtems.org/mailman/listinfo/devel
> 

-- 
--------------------------------------------
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.

More information about the devel mailing list