Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

Fri Oct 28 11:18:21 UTC 2022

Hello Chris,

Am 27.10.22 um 23:55 schrieb 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.

Yes, the consensus on what to use is the hardest part. Depending on the 
system there is more or less maintainence necessary. For the 
implementation I would strongly vote for a system that uses in-repo 
configuration files like the .gitlab.yml or .github directory (or many 
others) because it allows everyone to contribute. This also means that 
if (for example) I introduces a breaking change, I have to adapt the CI 
myself. I can't just say "I'm not able to adapt it. Sorry."

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

As soon as the system stabelizes, I might can set up the CI on the main 
branch (not pull-requests) to send mails to the list too. But I would 
like to test it a bit further before I start spamming the list accidentaly.

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

We usually run the testsuite on our new BSPs and I think Sebastian does 
some runs on some boards on bigger changes occasionally. But most of the 
time it's with some quick scritps and not integrated into the rtems-test 
tool. Therefore the format is different which is not ideal for the list.

At the moment we don't have any (for example) weekly runs planned on 
hardware (at least as far as I know).

Best regards

Christian

> 
> Chris

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