Amar Takhar created an issue: https://gitlab.rtems.org/administration/gitlab/-/issues/109
Assignee: Amar Takhar We have https://gitlab.rtems.org/contrib/ but these are read-only mirrors from upstream. We can't make modifications to these _plus_ we don't have CI for this namespace just https://gitlab.rtems.org/rtems/. On top of that `/contrib/` does not support out regular workflows which we want for maintaining our own port. This port will be upstreamed and sit at [https://www.micropython.org/](https://micropython.org/). We still need to develop this and have our own conversations before sending code upstream. This issue creates the first repository that will sit under [https://gitlab.rtems.org/rtems/contrib/](https://gitlab.rtems.org/contrib/) The purpose of this is to hold repositories where _we own_ the code and want to periodically upstream the changes made here. In the case of this development situation the workflow will be as follows: ```mermaid graph TD micropython.org --> /contrib/micropython/ /contrib/micropython/ --> /rtems/contrib/micropython/ /rtems/contrib/micropython/ --> micropython.org MR --> /rtems/contrib/micropython/ style MR color:#00C853 ``` The RSB will use the code from `/contrib/micropython/`This ensures that changes we need to consume are upstreamed first. In some cases such as EPICS where it takes a long time for changes to get merged we will use the one under `/rtems/contrib/` which could be the case for MicroPython. All regular RTEMS workflow including CI will be used on the micropython repository The default branch will be set to `rtems` where our development will go. This workflow has several advantages: 1. We get changes to the RTEMS namespace such as CI for free. 2. We will always be able to diff from the `rtems` branch to the `main` branch and see what differences need to be upstreamed creating a patch for this purpose is trivial and can be done via the GitLab UI. 3. Rebasing changes from the `main` branch to `rtems` will have to be done periodically but if there are conflicts upstream we will know when creating the MR. We can carry our own development and testing before upstreaming and ensure approvals / decisions have been made before submitting code. This is is a distinctly different workflow from `/contrib/` as this is to handle code that we own and are not contributing to upstream on behalf of the project. -- View it on GitLab: https://gitlab.rtems.org/administration/gitlab/-/issues/109 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
