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