We are loosing patches
Jan.Sommer at dlr.de
Jan.Sommer at dlr.de
Wed Sep 9 08:43:26 UTC 2020
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.
> -----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
> triggered by a comment from Chris here
> 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:
> 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
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> 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
More information about the devel