Hi all,
From my experience, gitlab is easier to manage than github when it comes to creating subgroups with dedicated maintainers. This can be the case for CentOS Automotive because, as an example, it might be useful to have some people responsible for the "V2X" subgroup when other people are in charge of the "Signaling" subgroup.
This can be "emulated" in github by having multiple organizations but the model is flat, so it's more difficult to maintain IMO.
Also another method we'll be applying soon in redpesk [1] is to simply have a 1:1 rule in the whole development/CI workflow: one "project" with "apps" in redpesk backend = one gitlab (sub)group to store sources = one gitlab (sub)group for gitpkgs = one output repository for RPMs = one .repo to add on a target board.
Things are then quite easy to understand (and also to isolate/sign/protect if needed). Of course, some more complex compositions can be done, but why introducing some complexity if it's not (yet) needed? Let's follow the KISS mantra!
My $0.02 :)
Best regards,
[1]: https://redpesk.bzh --- Stephane Desneux - CTO - IoT.bzh stephane.desneux@iot.bzh - www.iot.bzh
On 27/09/2021 20:57, Leigh Griffin wrote:
On Mon 27 Sep 2021, 16:35 Jeffrey Osier-Mixon, <jefro@redhat.com mailto:jefro@redhat.com> wrote:
Hi all - I'd be grateful to get some other voices in the mix. If anyone has any concerns about Gitlab, please let us know now before any work is done. Thanks!Absolutely let's get the conversation flowing, this is all git under the hood so moving things is possible if not with some effort involved. I'd like us to balance that with the need to make a decision and not suffer from analysis paralysis. The main thing for me is getting code open and available for contributions and usage!
Jeffrey "Jefro" Osier-Mixon | jefro@redhat.com <mailto:jefro@redhat.com> Red Hat Office of the CTO | Sr. Principal Community Architect, Automotive On Mon, Sep 27, 2021 at 1:14 AM Pierre-Yves Chibon <pingou@pingoured.fr <mailto:pingou@pingoured.fr>> wrote: On Fri, Sep 17, 2021 at 02:50:22PM +0100, Leigh Griffin wrote: > Hey everyone, > > This came up on the call yesterday to open a discussion about where we > should host our code and I'd like to open it up here for transparency on > the path forward. We have a lot of options in this sphere and all are Git > based. > > Historically, CentOS SIGs had their code hosted at https://git.centos.org/ <https://git.centos.org/>. > That's wired up to the CentOS Account system so users can login seamlessly. > Some SIGs have opted to host on Github as well and use their own Github > profile (which is not connected to their CentOS account). > > Currently, CentOS Stream is being built in the open at > gitlab.com/redhat/centos-stream <http://gitlab.com/redhat/centos-stream> where community contributors can create a > Gitlab account and interact with CentOS Stream. Gitlab is not currently > wired into the CentOS Account system and the team is working to get that > integration on the gitlab.com/CentOS <http://gitlab.com/CentOS> project (which is currently dormant). > > The suggestion put forward by Pierre-Yves Chibon, who is leading the effort > within Red Hat on creating the services and infrastructure for the SIG, is > to base ourselves on Gitlab. We can create a > gitlab.com/redhat/automotive-sig <http://gitlab.com/redhat/automotive-sig> project and mirror it at > gitlab.com/centos/automotive-sig <http://gitlab.com/centos/automotive-sig> so we can show people where we will work > once we've resolved the authentication question. The drawback is the need > to use a gitlab.com <http://gitlab.com> account, which, in time, we can merge into the CentOS > Account when the integration is completed. The key benefit of having us > base our code on Gitlab is the closeness to Stream from a codebase > perspective and the potential to use similar tools and approaches as their > development workflow. > > While no formal decision on where the overall CentOS SIGs will host their > code in the future has been made, the presence of Stream on Gitlab is > potentially future proofing us against a migration. > > Does the community have a strong preference for where we should base our > repos? I'm going to suggest we leave this topic percolate for a week to > have some dialog on the best path forward and then create our presence on > the source forge of choice. A week has passed and there hasn't been any strong preference voiced. We have checked Smooge's feedback and it looks like gitlab can do migration with redirect from the old location to the new one both at the http and the git level [1] so moving to the centos namespace as soon as it is available should be transparent. So I have asked for the project : https://gitlab.com/redhat/automotive/automotive-sig <https://gitlab.com/redhat/automotive/automotive-sig> to be created and we will soon be able to push to it :) Pierre [1] https://docs.gitlab.com/ee/user/project/repository/index.html#what-happens-when-a-repository-path-changes <https://docs.gitlab.com/ee/user/project/repository/index.html#what-happens-when-a-repository-path-changes> _______________________________________________ CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org <mailto:CentOS-automotive-sig@centos.org> https://lists.centos.org/mailman/listinfo/centos-automotive-sig <https://lists.centos.org/mailman/listinfo/centos-automotive-sig> _______________________________________________ CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org <mailto:CentOS-automotive-sig@centos.org> https://lists.centos.org/mailman/listinfo/centos-automotive-sig <https://lists.centos.org/mailman/listinfo/centos-automotive-sig>
CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org https://lists.centos.org/mailman/listinfo/centos-automotive-sig