We are loosing patches
Christian Mauderer
christian.mauderer at embedded-brains.de
Thu Sep 10 07:04:33 UTC 2020
On 09/09/2020 17:52, Gedare Bloom wrote:
> 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.
Thanks. Sounds like we are collecting points for a feature matrix.
Should I create a google docs table (or simmilar) so that we can collect
requirements and systems?
>
> 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.
I fully agree that we need the possibility for migration. But I'm not
100% convinced that self-hosted is the only possibility here. A good
backup strategy could do the same.
But let's assume it's a hard requirement that we are self hosted: I
think currently our servers are all running FreeBSD. Is that a hard
requirement too?
Background is: For example gitlab provides a great integration for
CentOS. You add the rpm-repo and get auto updates every month. We have
an installation at embedded brains that runs since some years with auto
updates enabled and I think we only had one problem due to the updates.
>
> 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).
Depending on whether we want a integrated system like gitlab or similar:
The system should be prepared to allow that. It most likely won't work
out of the box and like Joel said: Building the whole toolchain _and_
all BSPs needs a lot of CPU time.
If it's a standalone system like patchwork: Most likely it won't work
without a lot of additional scripting.
Note that buildbot currently does a part of that: Builds for the already
pushed commits.
>
> 3. Push from tool: to reduce the burden of downloading, testing, and
> then pushing.
Would be great, yes.
>
> 4. Sub-projects: we should be able to filter/sort by different repos.
> Notifications could go to separate mailing lists.
Agreed.
>
> 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.
Agreed. I don't really know what currently is done to keep our systems
allive. It works that well behind the scenes that I never had the
necessity to start looking (which is really great). But my first guess
would be that an integrated system might could be less work then keeping
multiple systems up to date and working together (after the initial
effort of the installation).
And yes: Fund-raising would be a good idea anyway. Regardless whether it
is to keep our current system running or update to anoter one.
>
> 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?
The integration with our other existing systems (not only Trac bur for
example buildbot too) is a really interesting question, yes. For example
gitlab would have most of the functionallity that we currently have too
(including wiki, ticket system, automated builds) and would provide
additional stuff like patch management, CI, .... Such features can be
enabled or disabled and I'm nearly sure that there are plugins for both
sides to provide integration.
PS: Sorry for my fixed view with gitlab. It's a system that I know.
Therefore I can use it as a reference. I'm open to other systems too
that provide the necessary functionallity.
Best regards
Christian
>
> 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
--
--------------------------------------------
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