search

knative / community

Knative governance and community material.
https://knative.dev/community
Other
244 stars 234 forks source link

Remove the usage google CLA choose between CNCF easyCLA vs DCO #90

Closed n3wscott closed 2 years ago

n3wscott commented 4 years ago

The @googlebot CLA handling is broken for multi-authors and github suggestion acceptance.

We should make a Knative CLA that does not use the Google CLA so we can allow for correct handling of multi-contributors.

see https://github.com/knative/pkg/pull/1066/#issuecomment-584777023 for the typical broken interactions with @googlebot CLA.

duglin commented 4 years ago

DCO!

n3wscott commented 4 years ago

@duglin I find DCO to be even more frustrating to use.

dprotaso commented 4 years ago

@duglin I find DCO to be even more frustrating to use.

I've contributed to envoy - it's just a matter of adding a -s like so

git commit -s
rgregg commented 4 years ago

I'm aware of a few issues with the Google CLA bot. I believe we've been working with the team that owns the tool to see if we can improve the issue for multiple owners. The good thing is that we can work around the tool as necessary. If there's more feedback we can take to the team to improve how the bot works on a project like this, I'd love to capture that feedback and share it.

With the structure of the project, the Google CLA is still required to be signed by all contributors or their organizations, which means we're not at the liberty to remove the Google CLA bot.

duglin commented 4 years ago

Can you elaborate? Are you saying the SC can’t change this if they wanted?

Sent from my iPad

On Feb 11, 2020, at 6:00 PM, Ryan Gregg notifications@github.com wrote:

 I'm aware of a few issues with the Google CLA bot. I believe we've been working with the team that owns the tool to see if we can improve the issue for multiple owners. The good thing is that we can work around the tool as necessary. If there's more feedback we can take to the team to improve how the bot works on a project like this, I'd love to capture that feedback and share it.

With the structure of the project, the Google CLA is still required to be signed by all contributors or their organizations, which means we're not at the liberty to remove the Google CLA bot.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

rgregg commented 4 years ago

Yes, with Google's ownership of the project and needing contributors to grant a license of the intellectual property, we need the Google contributor license agreement to be signed by all contributors. Creating our own Knative CLA bot to enforce a Knative-specific CLA would not be something that the steering committee can decide directly.

I'd like to better understand the impact of the CLA bot not functioning well in this scenario is causing to the overall productivity for the project, since that appears to be what this issue is about. If there are concerns with the contents or requirements of the Google CLA, I'm also interested in hearing those concerns, but I think that's a separate issue from what was raised here (although the two were conflated in the original post).

We always want to do the right thing for the community -- so I do want to make sure we understand the issue clearly.

duglin commented 4 years ago

While not a blocker for IBM, I do know that having a company specific CLA on an open source project does raise some eyebrows during our internal reviews. And I have heard from other companies that they've run into similar concerns and even roadblocks over it. This falls into the category of "bad optics" when trying to convince people that this really is an open-source project and not just a Google project that allows other people to participate.

This also is related to a question that I believe has been asked before... what exactly does the SC have control over? Most of the conversations have been around Google wanting to retain trademark enforcement, and now we have this. It begs the question... what other areas of control does Google have that people might assume are community/SC owned?

I still question why we can't just use DCOs? Even with "Google's ownership of the project" (which is an interesting phrase unto itself), a DCO should be allowable and help remove some barriers for people.

n3wscott commented 4 years ago

The good thing is that we can work around the tool as necessary.

The only folks who can work around it are from Google. Which leads to a lot of "haallllp I need a googler..."

mattmoor commented 4 years ago

Couple interesting articles that came up on a recent twitter thread:

Firecracker seems to use inbound=outbound (from the second article)

duglin commented 4 years ago

Quoting the first article:

Meanwhile, the issue of requesting the contributors' assent to the projects' license is
orthogonal to the issue of CLAs. Conservancy does encourage use of clear systems (either
formal or informal) for that purpose. One popular option is called the Developer Certificate of
Origin (DCO).
mattmoor commented 4 years ago

I don't understand why the CLA bot won't even rescan for non-Googlers 🙄

See here: https://github.com/knative/net-contour/pull/108#issuecomment-619187191

thisisnotapril commented 4 years ago

Bot issues aside; I believe everyone on the thread is covered by a corporate CLA already. Information on the Google CLA and the reasoning is here: https://opensource.google/docs/cla/policy/

thisisnotapril commented 4 years ago

I don't understand why the CLA bot won't even rescan for non-Googlers 🙄

See here: knative/net-contour#108 (comment)

That's a good point; I'll ask the team about it and see what we could potentially do to make that process easier. Has there been any success with closing and reopening PRs and force a rescan? That works in other orgs with other bots; curious if it would work here.

vaikas commented 3 years ago

There's some work in redoing the robot to make it less cumbersome. @thisisnotapril to follow up with the team on rough timelines, etc.

vaikas commented 3 years ago

@thisisnotapril do you happen to have any updates on this issue?

thisisnotapril commented 3 years ago

Current ETA for the new bot is end of Q2

dprotaso commented 3 years ago

What's fixed in the new CLA bot?

vaikas commented 2 years ago

Just a quick update on this from yesterdays SC meeting. @thisisnotapril said the target for the new CLA bot is Nov 1st. It will make multi-author / cp much easier. Also anybody with commit rights can trigger a rescan of the CLA. Flipping the bit still requires Googler magic.

vaikas commented 2 years ago

Did the new bot get deployed? @thisisnotapril

vaikas commented 2 years ago

Today (2022-03-03) during the Steering Meeting we discussed switching over to the DCO. As part of the CNCF onboarding, we need to decide on which one we are using. Steering is leaning towards using DCO for a few reasons. Here's main reasons for switching to DCO:

rgregg commented 2 years ago

It's exciting to see progress on this front and moving towards a better solution here!

pmorie commented 2 years ago

Here is how I see the scope of choice here:

Some companies can't really sign the CLA for one reason or another.

This got me thinking about how to model the choices here.

Ack that as an issue that we know was present with the Google CLA. Do we know of specific examples where potential contributors are prevented from signing the CNCF CLA? I am not attempting to express skepticism that some folks may be in that situation, but I would be willing to bet that CNCF CLA is lower friction than one specific to a particular company.

I also wonder what the relative frequency of cases where potential contributors may be prevented from using a DCO is. Do we have any idea?

I think these are the buckets of people to quantify:

  1. People who have already signed the CNCF CLA and would have zero friction to new contributions if we adopted the CNCF CLA
  2. People who have not already signed the CNCF CLA, could sign the CLA, could use DCO
  3. People who have not already signed the CNCF CLA, could not sign the CLA, could use DCO
  4. People who have not already signed the CNCF CLA, could sign the CLA, could not use DCO

Are those the right buckets? I think we should be framing our choice around the relative quantities of these different buckets. Thoughts?

lance commented 2 years ago

I believe that most current contributors to any CNCF project have signed the CLA (but I have no proof of this beyond the fact that the CNCF CLA existed before the CNCF allowed the use of DCO)

Only a single data point, but I for one have not. I do contribute to and maintain CNCF projects that use DCO. I have signed the Google CLA as an individual contributor, however.

  1. People who have already signed the CNCF CLA and would have zero friction to new contributions if we adopted the CNCF CLA

I believe that the CLA / DCO requirement applies to each project. I could be mistaken, but as I understand it, there is not a blanket CLA for all CNCF projects. So there is no scenario where users have zero friction. In any case, the requirements in https://github.com/cncf/toc/issues/794 say that each project in the knative and knative-sandbox organizations will need to enable either EasyCLA or DCO in their GitHub orgs. I'm not sure if we will be able to have a single CLA that covers all repositories, but that seems like a reasonable expectation. If this is the case, then the buckets might be more like this.

  1. People who could sign the CLA, could use DCO
  2. People who could not sign the CLA, could use DCO
  3. People who could sign the CLA, could not use DCO

But I'm not sure there really is anyone who fits that last bucket. Using DCO is just adding a signature at the bottom of each commit, declaring yourself as the author, e.g.

Signed-off-by: Lance Ball <lball@redhat.com>

If we can also eliminate the group of those who cannot use DCO as a bucket, then we end up with

  1. People who could sign the CLA, could use DCO
  2. People who could not sign the CLA, could use DCO

Meaning there simply are more people who can use DCO vs CLA (if you accept all of my statements above, anyway). But the biggest bucket doesn't really mean it's the right answer, if using the DCO is considered to be too much friction. The DCO requires action on every commit, whereas the CLA is once and done. I personally don't have very strong feelings, but I use DCO for CloudEvents and --signoff just what my fingers do naturally when I'm typing git commit now, so I don't find it to be burdensome. That may not be the case for everyone.

pmorie commented 2 years ago

I could be mistaken, but as I understand it, there is not a blanket CLA for all CNCF projects.

I believe there is one and only one. Let’s find out for sure.

pmorie commented 2 years ago

But I'm not sure there really is anyone who fits that last bucket. Using DCO is just adding a signature at the bottom of each commit, declaring yourself as the author, e.g.

The mechanical steps are one thing, whether your organization permits you to do that is another. The permission dimension is the one I was referring to. Does that make sense?

lance commented 2 years ago

I could be mistaken, but as I understand it, there is not a blanket CLA for all CNCF projects.

I believe there is one and only one. Let’s find out for sure.

If this is the case, then it does reduce friction, IMO.

n3wscott commented 2 years ago

There is also this: https://easycla.lfx.linuxfoundation.org/

lance commented 2 years ago

I wrote

I'm not sure if we will be able to have a single CLA that covers all repositories, but that seems like a reasonable expectation.

Scott wrote

There is also this: https://easycla.lfx.linuxfoundation.org/

It looks like EasyCLA will allow us to have one CLA covering all repos, based on my reading of this.

Project managers and maintainers can set up EasyCLA to automatically discover and protect new repositories, or can keep direct control over which repos are protected. (https://lfx.linuxfoundation.org/tools/easycla)

This is not the same as a blanket CNCF CLA (I am skeptical about that even being a thing), but it is "once and done" for ALL Knative repos, which is appealing.

csantanapr commented 2 years ago

Related to [INCUBATING PROJECT ONBOARDING] Knative https://github.com/cncf/toc/issues/794

csantanapr commented 2 years ago

I asked in the CNCF Slack #easycla channel about the CLA vs. DCO here what I got back

vaikas commented 2 years ago

Unless something else comes up, we're going to finalize the switch to EasyCLA next Thursday: 2022-03-31.

Speak up if you have grave concerns or additions to the great discussion of pros/cons above.

thisisnotapril commented 2 years ago

Are we still moving forward with the switch to EasyCLA? Looks like the Google CLA is still in place here.

vaikas commented 2 years ago

Yes, that was the decision.

thisisnotapril commented 2 years ago

Who is on point for the switch? Wondering what we need to do next.

vaikas commented 2 years ago

@csantanapr is driving it here: https://github.com/knative/community/issues/952

lance commented 2 years ago

I've got it now per https://github.com/knative/community/issues/952#issuecomment-1112442491

I have a couple of open tickets - one with the Linux Foundation and one with CNCF, to get access to the EasyCLA dashboard/portal before I can set it all up for Knative.

upodroid commented 2 years ago

@hh ^