On Wed, Sep 9, 2020 at 8:16 AM Christian Mauderer <christian.maude...@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.som...@dlr.de > > <mailto:jan.som...@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-boun...@rtems.org > > <mailto:devel-boun...@rtems.org>> On Behalf Of Christian Mauderer > > > Sent: Wednesday, September 9, 2020 10:24 AM > > > To: RTEMS Devel RTEMS <devel@rtems.org <mailto:devel@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.maude...@embedded-brains.de > > <mailto:christian.maude...@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@rtems.org <mailto:devel@rtems.org> > > > http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ > > devel mailing list > > devel@rtems.org <mailto:devel@rtems.org> > > http://lists.rtems.org/mailman/listinfo/devel > > > > -- > -------------------------------------------- > embedded brains GmbH > Herr Christian Mauderer > Dornierstr. 4 > D-82178 Puchheim > Germany > email: christian.maude...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
