Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move from CLA to DCO #2649

Closed
dims opened this issue Sep 8, 2018 · 12 comments

Comments

Projects
None yet
9 participants
@dims
Copy link
Member

commented Sep 8, 2018

Following up on an old email thread [1]. I understand that Kubernetes was using Google CLA before and hence naturally moved to using CNCF CLA [2].

  • Since CNCF does allow projects to use DCO, is there a possibility that Kubernetes can move to it?
  • What are the pros and cons of DCO vs CLA?
  • Will using DCO help attracting a larger set of contributors? (we have anecdotal evidence of folks unable to create PR(s) or not following up on PR(s) when the bot marks them red)

[1] https://groups.google.com/forum/#!msg/kubernetes-sig-apps/71c1FHem3-Y/hy9AnS34BgAJ
[2] https://docs.google.com/document/d/1LIwyn5PDSYu8kh-7hH8688lt1cvwATkZmhec13nhp1c/edit#heading=h.tm8xljbp3pt0

@neolit123

This comment has been minimized.

Copy link
Member

commented Sep 10, 2018

one good benefit of CLA is that it's integrated per github account.

i've been helping with reviews for the DCO integration:
kubernetes/test-infra#9197 (comment)

overall DCO is more fragile for contributors:

  • DCO has to be manually added per each commit.
  • auto-squash semantics nuke the DCOs and GPGs. this is quite bad and the project needs to outline this in the contributor guide. but then if the DCO is nuked, how is the contributor allowed to contribute to the project?
  • contributors can give a completely invalid email in their Signed-off-by: line and probably nobody would have the time to verify it. also they can use this which i'm pretty sure conflicts with the DCO definition.
@cblecker

This comment has been minimized.

Copy link
Member

commented Sep 10, 2018

I think this discussion may need to start with the steering committee to see if it's even a possibility from their perspective. I personally like the CLA approach, but think there is value in discussing the pros/cons.

@cblecker

This comment has been minimized.

Copy link
Member

commented Sep 10, 2018

@thockin

This comment has been minimized.

Copy link
Member

commented Sep 10, 2018

@parispittman

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2018

side note to thockins comment: there is a cla question going out on the contributor experience survey (launching this afternoon PT time). it's not a standalone question but ranks 1-5 how much of a challenge it is for the contributor.

@spiffxp

This comment has been minimized.

Copy link
Member

commented Oct 5, 2018

I asked about this Jan 2018: https://groups.google.com/a/kubernetes.io/d/msg/steering/B32ZXpw8EG8/aCx5yhdfCwAJ

Final response from thockin was:

I spoke with Google legal, who feel strongly that NOT having a CLA
represents a liability to all consumers of the project, and urge every
CNCF project to adopt the CLA.

@spiffxp

This comment has been minimized.

Copy link
Member

commented Oct 5, 2018

/committee steering

@philips

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2018

Personally I am apathetic. CLA is a one time horrible UX. DCO is an ongoing horrible UX.

@dims

This comment has been minimized.

Copy link
Member Author

commented Oct 8, 2018

@philips true enough. The intent was about making things easier for occasional contributors.

@cblecker

This comment has been minimized.

Copy link
Member

commented Oct 9, 2018

If all things were equal legally (I understand that they probably aren't), it would be a disruption to take our existing contributor base and change their workflow. While CLA is a one-time impact on new contributors, DCO would require workflow changes from everyone. There would need to be a bunch of added value IMO to consider doing this.

@fejta-bot

This comment has been minimized.

Copy link

commented Jan 7, 2019

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@cblecker

This comment has been minimized.

Copy link
Member

commented Jan 7, 2019

@cblecker cblecker closed this Jan 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.