Closed mcleo-d closed 8 months ago
Hi @mcleo-d it looks like FINOS already have a GitLab account so we already have precedent. Perhaps it's a question for @maoo - whether GitLab is something that the FINOS team actively support?
It is my understanding that the Linux Foundation needs to support their CLA tool on GitLab as currently it is only supported on GitHub. This would be the first barrier to leveraging GitLab for FINOS projects.
It would be great to understand the appetite of FINOS, FINOS members and the community as this might need to be added to a wider roadmap.
It would be great to understand the appetite of FINOS, FINOS members and the community as this might need to be added to a wider roadmap.
Agreed, so thanks for raising @mcleo-d
And as @ColinEberhardt mentions, we host code in our gitlab org, the Legend modeling initiatives; we never hosted software projects, but shouldn't be more different than that.
Please allow me some time to work with the LFX team and make sure we have all tools ready and configured to host code on Gitlab. TY!
Hey @maoo - Is there a path through Apache2 / DCO that could be followed as an interim?
I'm just understanding a potential roadmap path.
No commitments.
Hey @maoo - Is there a path through Apache2 / DCO that could be followed as an interim?
DCO would be possible, yes, and it would remove the need for EasyCLA, but there would still be some LFX tools that we would like/need to integrate, and that's what I'd like to figure our in the next days.
I'm just understanding a potential roadmap path.
No commitments.
Totally understandable! I'll try to get back to you on this ASAP.
Hey @maoo - Do you have any updates on your conversation with the LF infra team?
Speak soon,
James.
Hi @mcleo-d , I've scheduled a meeting with the LF team next week, I'll let you know what comes out of it.
Nick here, GitLab Team Member
On the topic of EasyCLA (LF) & GitLab. I've worked with the LF in the past to get GitLab support for the EasyCLA project.
That should be supported since mid '22 (https://gitlab.com/gitlab-com/marketing/developer-relations/open-source-program/consortium-memberships/-/issues/100#note_1264933162), see also https://docs.linuxfoundation.org/lfx/easycla/v2-current/project-managers/add-and-manage-gitlab-groups
If you commit with the CLI, contributors should be OK to accept the DCO. There is an open epic (https://gitlab.com/groups/gitlab-org/-/epics/8456) to add support to the web interface. Contributions are welcome!
There is a push rule that prevents commits to be pushed if they are not signed, and in effect did not adhere to the DCO. This ensures compliance, but due to the WebIDE lacking the "checkbox" to sign the commit, it does cause a DX-regression. https://docs.gitlab.com/ee/push_rules/push_rules.html#custom-push-rules
@mcleo-d - trying to take off my GitHub employee hat and leave on my OSS participant one.
The source of the question stems from creating a positive engineering experience, reducing engineering friction, reducing context switching and maximising engineering efficiencies when moving from one system of engineering to another.
For whom would this reduce friction and for whom would it add friction? I ask because members and contributors use a variety of version control systems for internal work, including:
And, in most all cases, members and contributors have different identities within their internal systems than are used in public forums as most internal development is performed with accounts that are IdP-managed.
I'd also be concerned about a bifurcated experience. Most OSS projects/foundations/etc. have standardized on a single place for managing their projects. Discovery and participation can be significantly hampered when spread across multiple systems and doing so requires persons who contribute to projects in both systems to maintain identities in each (a work identity and multiple OSS identities) which I'd argue only adds to the perceived friction.
While I've certainly got biased opinions about which system should be used, I am also of the opinion getting all people into a single system (whether for internal or OSS development) creates the best environment for collaboration, discovery, and growth of shared projects - no matter which system is ultimately chosen.
@pholleran I agree this is a challenge with so many git solutions being centralized instead of decentralized. This concern came up in the last CCC meeting where a number of companies are using solutions that don't sync a corporate identity to GitHub leaving users to leverage personal accounts. The way the LF configured the CLA for OSS contributions, individuals need to use their corporate email as their identity to be covered under their corporate CLA for FINOS. A number of FINOS companies who are using alternative git providers from GitHub SaaS do not have their internal identity sync'd nor are they allowed to create an account on GitHub using their corporate email address. There were even a couple FINOS members on our last call that had mentioned GitHub is blocked from their internal networks and only their organization is whitelisted so they can't access the FINOS organization. With a number of FINOS companies using alternative git providers, does it make sense to allow them to use a solution where they can contribute through an approved solution while still maintaining the culture and community that FINOS represents. I believe @mcleo-d was thinking specifically GitLab as an alternative due to the number of FINOS members that are GitLab customers.
Nick here, GitLab Team Member
On the topic of EasyCLA (LF) & GitLab. I've worked with the LF in the past to get GitLab support for the EasyCLA project.
- That should be supported since mid '22 (https://gitlab.com/gitlab-com/marketing/developer-relations/open-source-program/consortium-memberships/-/issues/100#note_1264933162), see also https://docs.linuxfoundation.org/lfx/easycla/v2-current/project-managers/add-and-manage-gitlab-groups
- If you commit with the CLI, contributors should be OK to accept the DCO. There is an open epic (https://gitlab.com/groups/gitlab-org/-/epics/8456) to add support to the web interface. Contributions are welcome!
- There is a push rule that prevents commits to be pushed if they are not signed, and in effect did not adhere to the DCO. This ensures compliance, but due to the WebIDE lacking the "checkbox" to sign the commit, it does cause a DX-regression. https://docs.gitlab.com/ee/push_rules/push_rules.html#custom-push-rules
Hey @nickveenhof ππ»
Thanks so much for replying to this issue. It's great to see the GitLab open source community providing support and answers to this request.
I'm working with @maoo and FINOS on a potential route forward as I'm still testing the appetite of the community rather than requesting a formal solution right now.
Please keep the conversation going as the appetite and momentum builds.
All the best,
James.
Hey @pholleran and @leefaus,
Thanks so much for your insights and experience. I'll take your points on board as I move forward with my exploration of potential contribution solutions. I'm happy to talk more in a future FINOS SIG where I'll add more context.
The way the LF configured the CLA for OSS contributions, individuals need to use their corporate email as their identity to be covered under their corporate CLA for FINOS. A number of FINOS companies who are using alternative git providers from GitHub SaaS do not have their internal identity sync'd nor are they allowed to create an account on GitHub using their corporate email address. There were even a couple FINOS members on our last call that had mentioned GitHub is blocked from their internal networks and only their organization is whitelisted so they can't access the FINOS organization.
@leefaus - There are many barriers that need to be cleared for engineers to contribute externally. This is a great use case for @psmulovics and Open Source Readiness and @rhyddian on his experience for banks to have engineering OSPOs.
James.
Hey @pholleran and @leefaus,
Thanks so much for your insights and experience. I'll take your points on board as I move forward with my exploration of potential contribution solutions. I'm happy to talk more in a future FINOS SIG where I'll add more context.
The way the LF configured the CLA for OSS contributions, individuals need to use their corporate email as their identity to be covered under their corporate CLA for FINOS. A number of FINOS companies who are using alternative git providers from GitHub SaaS do not have their internal identity sync'd nor are they allowed to create an account on GitHub using their corporate email address. There were even a couple FINOS members on our last call that had mentioned GitHub is blocked from their internal networks and only their organization is whitelisted so they can't access the FINOS organization.
@leefaus - There are many barriers that need to be cleared for engineers to contribute externally. This is a great use case for @psmulovics and Open Source Readiness and @rhyddian on his experience for banks to have engineering OSPOs.
James.
"The way the LF configured the CLA for OSS contributions, individuals need to use their corporate email as their identity to be covered under their corporate CLA for FINOS" <<< Is this correct? We have approved FINOS contributors in LFX CLA Manager using non-corporate email addresses.
Great point, @mcleo-d , @robmoffat and I would add it to the next OSR call as a topic. I actually started thinking about, e.g. I do not have access to gitlab, but do have for github. Instead of doing all the effort again, we can try to use something like gitproxy ( @sammoorhouse , you interested?).
Hey @pholleran and @leefaus, Thanks so much for your insights and experience. I'll take your points on board as I move forward with my exploration of potential contribution solutions. I'm happy to talk more in a future FINOS SIG where I'll add more context.
The way the LF configured the CLA for OSS contributions, individuals need to use their corporate email as their identity to be covered under their corporate CLA for FINOS. A number of FINOS companies who are using alternative git providers from GitHub SaaS do not have their internal identity sync'd nor are they allowed to create an account on GitHub using their corporate email address. There were even a couple FINOS members on our last call that had mentioned GitHub is blocked from their internal networks and only their organization is whitelisted so they can't access the FINOS organization.
@leefaus - There are many barriers that need to be cleared for engineers to contribute externally. This is a great use case for @psmulovics and Open Source Readiness and @rhyddian on his experience for banks to have engineering OSPOs. James.
"The way the LF configured the CLA for OSS contributions, individuals need to use their corporate email as their identity to be covered under their corporate CLA for FINOS" <<< Is this correct? We have approved FINOS contributors in LFX CLA Manager using non-corporate email addresses.
No, that is not correct - the tool allows a wide variety of ways to add someone to your organisations CLA. I manage our CLA coverage and allow people to use their personal or corporate email / GitHub identification.
It has the features, but the user experience is rather lacking, meaning that it isnβt always obvious what you can and cannot do π
Here's the docs with the different approval criteria that can be used - https://docs.linuxfoundation.org/lfx/easycla/v2-current/corporate-cla-managers/approve-and-manage-contributors#add-contributor-s
Hey @maoo - It would be good to continue the momentum of this thread. Can you let me know if I am missing actions or updates from the wider LF or GitLab? Speak soon.
Hi @mcleo-d - I've validated this with the LF team, and while some of the LFX platform tools do not support GitLab yet (in roadmap for H2), FINOS is ready to host projects on Gitlab.
I hope this answer your initial question, feel free to close the issue.
Thank you for clarifying @maoo. I have closed this issue and will be in touch later this year.
Exploring the appetite for public FINOS GitLab
As FINOS members, the NatWest OSPO would like to know whether there's an appetite within FINOS for specific FINOS projects to be contributed, developed and maintained using the public FINOS GitLab?
The source of the question stems from creating a positive engineering experience, reducing engineering friction, reducing context switching and maximising engineering efficiencies when moving from one system of engineering to another.
Thank you for your time and consideration as open source at NatWest is roadmapped for 2024.
James.