Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

[Christian MAUDERER]

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.mauderer at 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/