We are loosing patches
Gedare Bloom
gedare at rtems.org
Wed Sep 9 15:52:23 UTC 2020
On Wed, Sep 9, 2020 at 8:16 AM Christian Mauderer
<christian.mauderer at embedded-brains.de> wrote:
>
> 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.
>
This is a good idea to address a clear problem. We should identify the
requirements and options.
Some initial requirements:
1. Self-hosted: I guess we want self-hosting or at least control of
the data so we can easily retain it for the future and migrate it if
necessary.
2. Testing: At least a compile-only test, if not a simulator test
result. This shouldn't be a full CIT, just enough to say it compiles
(maybe runs) for some BSP(s).
3. Push from tool: to reduce the burden of downloading, testing, and
then pushing.
4. Sub-projects: we should be able to filter/sort by different repos.
Notifications could go to separate mailing lists.
5. Balance admin burden: we should try to balance reducing the burden
on contributors/committers with increase in admin. Either by finding
reasonably low-overhead products to use, or by fund-raising for
infrastructure.
I'm not so familiar with the options for patch management. Some
integrate with ticket management systems. Would that help, or are we
happy with Trac?
Just a few thoughts to add here,
Gedare
> 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.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
More information about the devel
mailing list