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 at 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 at redhat.com > <mailto:jefro at 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 at redhat.com <mailto:jefro at 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 at pingoured.fr > <mailto:pingou at 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 at centos.org <mailto:CentOS-automotive-sig at 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 at centos.org <mailto:CentOS-automotive-sig at 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos-automotive-sig >