Am 26.10.22 um 01:06 schrieb Chris Johns:
On 26/10/2022 4:46 am, Joel Sherrill wrote:
In general, our current approach is quite a hack. We should do things
more event driven. For example, if you want to update the RSB, then you
create a pull request. This pull request starts a CI script which
updates the mirrors and builds the RSB on a selected set of platforms.
If everything is all right, the pull request can be merged.
Just getting to the point where a pull request triggered an update would
be useful. Assuming a pull request with no content would be ok.
I feel starting to have pull requests will only result in changes being posted
there by users who see pull requests as active. It is reasonable for a user to
think this. Who will then field those and merge them?
Chris
Hello Chris,
I agree that as long as the RTEMS project doesn't officially use pull
requests, it's not a good idea to have something that looks official but
isn't used. On the other hand, I think that it would be a really good
idea for the RTEMS project to migrate to a patch management system where
a pull-request with automated CI run is the official method for
contributing. That would take a lot of work from the shoulders of the
maintainers because for a lot of patches, no more manual tests whether
the patch builds would be necessary. Of course the patch would still
need review.
Beneath that, a system with pull requests usually has a nice overview
over pending patches. At the moment we have patches on the mailing list
mixed with discussions. A user has to get the attention of a maintainer
to get a patch merged. Users that don't want to be pushy maybe don't
ping such patches or some might just forget that they send a patch to
the list. I'm sure that we lost quite a few patches due to that because
no one felt responsible, no one noted the patch or no one had the time
to test the patches before merging them.
I know that I have even lost some of my own patches on the list because
no one acknoledged them and I started to work on something else and
forget them. I found some a few months later and was surprised that I
didn't push them. I wouldn't guarantee that I found all of them. A patch
management system should help to see whether there are still open ones.
PS: I already mentioned it in another mail: I started to build some
github CI scripts that we at embedded brains want to use for testing our
own public patches. Github doesn't seem to limit the CI time on public
projects so everyone who wants to play a bit with it: Feel free to
create pull requests to see how something like that works. Just select
the "ci" branch on
https://github.com/embedded-brains/rtems
That repo is clearly a fork (marked with "forked from RTEMS/rtems" so I
don't see the risk that someone mixes it up with the official repos. But
if unknown users will use it to create pull requests, I'll add a comment
to the pull requests, that patches should be sent to the mailing list
instead. If there are a lot of unknown users, I'll automate the comments.
Best regards
Christian
--
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
