Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

[Chris Johns]

Hi Christian,

Thank you for your considered comments.

On 27/10/2022 12:06 am, Christian MAUDERER wrote:
> 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.

I would love a patch management system to be in place. Getting consensus on what
to use, how we host it, who does the work and who maintains it is hard.

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

No question that would be the case. A good tool will also manage CI to make sure
we have buildable commits entering the repo.

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

Yes this is true and I would like to add pull requests are widely used and
people know how to use them and trust them and this is important for us long
term. We need to stay current in the tools and methods we employ.

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

Agreed. I am guilty of forgetting.

> 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 also think this is true.

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

Good to know I am not the only one.

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

Yes I remember, maybe on discord. I took a look and it is nice. It is great to
see support companies running CI flows. OAR has tools builds and simulator test
runs posting to build results to the builds list and this is great and important.

I would like to see more hardware test runs and posted results. Does EB have any
plans to run the testsuite on hardware and post the results to builds?

Chris