Kubernetes: Problème Umbrella pour le système CLA de la Linux Foundation (CNCF)

Créé le 21 juin 2016  ·  152Commentaires  ·  Source: kubernetes/kubernetes

Étant donné que les actifs IP de Kubernetes appartiennent à la Cloud Native Computing Foundation (CNCF), il est temps pour nous de passer au système CNCF CLA. Nous testerons d'abord la version bêta sur un référentiel de test avant de le déployer partout. cc: @bgrant0607

lifecyclfrozen sicontributor-experience

Commentaire le plus utile

D'accord, @emsearcy , cela a fonctionné comme un charme. Merci. Je vais contacter mon fournisseur de messagerie et essayer de les amener à résoudre ce problème.

J'ai fait un petit article à ce sujet ci-dessous que nous pouvons, espérons-le, ajouter à https://github.com/kubernetes/kubernetes/wiki/CLA-FAQ

Parce que GitHub Wiki n'autorise pas actuellement les contributions extérieures, ci-dessous compte comme une contribution basée sur la licence que je viens de signer :)

Je ne reçois pas d'e-mail contenant le CLA pour les accords de contributeur individuel.

@emsearcy explique dans
https://github.com/kubernetes/kubernetes/issues/27796#issuecomment -303234338
que certains utilisateurs de certains fournisseurs de messagerie (à savoir FastMail) rencontraient
problèmes de délivrabilité avec les e-mails du fournisseur de signature électronique, HelloSign. Jusqu'à ce
est corrigé, la solution de contournement suivante est disponible :

  1. Créez un compte sur HelloSign en utilisant le même email pour le CLA.
  2. Accédez à la section "Documents" à l'aide de la barre de navigation de gauche et appuyez sur la touche
    Bouton "Signer" pour "Contrat de Licence Contributeur Individuel CNCF".
    HelloSign Documents Section
  3. Révisez et signez, si vous le souhaitez.
    HelloSign Signing Page
  4. Confirmez que l'accord a été signé dans la section "Documents".
    HelloSign Documents Section Confirmed
  5. Si vous avez un PR existant avec cncf-cla: no , attendez 5 minutes pour HelloSign
    et les serveurs CI pour résoudre le nouvel accord. Laisser un nouveau commentaire sur
    PR, et le libellé cncf-cla: no devrait devenir un cncf-cla: yes .
    CLA Fixed

Réduction:

### I'm not getting an email containing the CLA for Individual Contributor Agreements.

<strong i="40">@emsearcy</strong> explains in
https://github.com/kubernetes/kubernetes/issues/27796#issuecomment-303234338
that some users of certain email providers (namely FastMail) were experiencing
deliverability issues with emails from the e-signing vendor, HelloSign. Until this 
is redressed, the following workaround is available:

1. Create an account on [HelloSign](https://hellosign.com) using the same email for the CLA.
2. Go to the "Documents" section using the left navigation bar and press the
   "Sign" button for "CNCF Individual Contributor License Agreement".
   ![HelloSign Documents Section](https://i.imgur.com/n6o6KzO.png)
3. Review and sign, if desired.
   ![HelloSign Signing Page](https://i.imgur.com/Tcyms6C.png)
4. Confirm that the agreement has been signed in the "Documents" section.
   ![HelloSign Documents Section Confirmed](https://i.imgur.com/99QWSNu.png)
5. If you have an existing PR with `cncf-cla: no`, wait 5 minutes for HelloSign
   and the CI servers to resolve the new agreement. Leave a new comment on the
   PR, and the `cncf-cla: no` label should become a `cncf-cla: yes`.
   ![CLA Fixed](https://i.imgur.com/pKhLQH5.png)

Tous les 152 commentaires

Pouvez-vous décrire le processus de migration des CLA ?

@smarterclayton , nous informerons la communauté dès que le nouveau système sera opérationnel, il y a quelques approches dont nous discutons pour minimiser toute perturbation du flux de travail

Nous effectuerons la transition vers le CLA de la Cloud Native Computing Foundation sur tous les référentiels kubernetes dans un avenir proche.
Cette transition devrait se produire dans tous nos référentiels au cours de la semaine du 10/3.

À partir d'aujourd'hui, nous testons le nouveau mécanisme CLA dans le référentiel kubernetes/contrib.
Le bot Google CLA fonctionnera en parallèle avec le bot CNCF CLA jusqu'au 10/3.
Veuillez noter que les fusions PR et la file d'attente de soumission ne sont pas bloquées à la signature de la CNCF CLA pour le moment, mais le seront lorsque nous aurons terminé la transition.

Afin de minimiser les perturbations du flux de travail, si vous êtes un contributeur,
veuillez visiter https://identity.linuxfoundation.org/projects/cncf et signer le CLA en tant qu'individu ou employé, selon le cas.
S'il y a des problèmes, veuillez les mentionner dans le problème de suivi à : https://github.com/kubernetes/kubernetes/issues/27796

Étapes à venir :

  • [x] La file d'attente de soumission doit respecter les étiquettes cncf-cla.
  • [x] Les libellés cla-oui/non du googlebot doivent être supprimés des référentiels.
  • [x] Activez le webhook CNCF à l'échelle de l'organisation et désactivez le bot Google CLA.

Salut, je veux signer le CLA individuel et la page hellosign à la fin demande un "Titre" (Signature, nom, titre et date).

Je ne sais pas trop quoi mettre sur le titre. J'ai essayé de regarder https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md et le CLA précédent et aucun titre n'était requis (ni demandé). Je suis étudiant en informatique.

Que dois-je utiliser comme titre ? Ou est-ce là exprès ou peut-être est-ce un reste?

Merci!

@rata , je pense qu'un titre "Etudiant" est une bonne solution. @caniszczyk , pourriez-vous confirmer ?

@sarahnovotny Étudiant ou N/A c'est bien

@sarahnovotny @caniszczyk : merci beaucoup !

@sarahnovotny , @caniszczyk , il semble que Redhat ait des problèmes avec la CNCF CLA. Pouvez-vous les aider? Il peut s'agir d'un problème avec la CLA de l'entreprise ou d'un problème technique et nous n'en sommes pas sûrs.

cc @eparis @ingvagabund

@eparis , que se passe-t-il lorsque vous allez sur https://identity.linuxfoundation.org/projects/cncf et que vous choisissez "Contribuer en tant qu'employé" ? Cela devrait vous inviter à associer votre compte GitHub, ce qui n'a pas encore été fait.

(Ceux qui sont autorisés à gérer les contributeurs autorisés pour leurs entreprises ne sont pas automatiquement configurés en tant que contributeurs eux-mêmes ; le système s'attend toujours à ce qu'ils s'inscrivent en tant que contributeurs à des fins de suivi.)

@emsearcy J'ai envoyé un e-mail à @caniszczyk
mais quand je vais sur ce lien j'obtiens
Your organization is not authorized under a Corporate Contributor License Agreement. If you have signed agreements, please check back later or use the contact form below.

@emsearcy existe-t-il un moyen de discuter en privé ? Envoyez moi un email? eparis chez redhat ?

Je rencontre un bogue avec le système de compte sur https://identity.linuxfoundation.org. Qui dois-je contacter à ce sujet ?


Impossible de changer le mot de passe sur les comptes créés via les crédits github

  • Compte créé avec github. Jamais créé de mot de passe
  • Je suis allé changer mon adresse e-mail
  • On m'a dit que j'avais besoin d'un mot de passe pour changer d'adresse e-mail
  • E-mail de demande de réinitialisation du mot de passe
  • Lien suivi dans l'e-mail
  • Cliquez sur "lien de réinitialisation du mot de passe"
  • On m'a dit que j'avais besoin d'un mot de passe pour changer mon mot de passe

@jbeda , je suppose que vous étiez toujours connecté ? (La page de réinitialisation du mot de passe indique "Vous devez vous déconnecter pour utiliser le lien de réinitialisation du mot de passe dans l'e-mail"). Sinon, il indique que vous êtes toujours connecté lorsque vous essayez de l'utiliser.

J'ai essayé de "m'inscrire en tant qu'employé", et je suis allé jusqu'à "Veuillez contacter quelqu'un au sein de votre organisation qui est responsable de la supervision des collaborateurs autorisés pour ce projet".

Ce serait moi; et ensuite?

@bboreham demandez à votre entreprise/organisation de s'inscrire ici https://identity.linuxfoundation.org/node/285/organization-signup

@caniszczyk ce que j'ai fait :

  • Visitez votre URL.
  • Connectez-vous via Google.
  • Cherchez un moyen de déclarer mon organisation et son personnel.
  • Je suis revenu ici.

Pouvez-vous dire exactement où je clique pour que l'organisation (Weaveworks, Inc) s'inscrive ?

@bboreham avec ce lien, il existe un moyen d'inscrire votre organisation et de signer électroniquement la CLA d'entreprise, une fois que vous aurez fait cela, vous pourrez faire tout le reste

Pour moi, le moyen était d'ouvrir une fenêtre de navigateur "incognito", puis après m'être reconnecté, le formulaire a été présenté. Aucune quantité de déconnexion ou de clic dans la fenêtre d'origine ne ferait apparaître ce formulaire.

Il semble y avoir des problèmes avec la CLA d'entreprise de la CNCF. @euank devrait être couvert par la CLA d'entreprise pour CoreOS, cependant

ne reflète pas cela.

@caniszczyk pourriez-vous s'il vous plaît jeter un œil au problème que @calebamiles a mentionné ci-dessus ?

Il semble que @euank n'ait qu'à cliquer sur "Contribuer en tant qu'employé" et sera automatiquement associé à CoreOS CCLA.

Oui, merci @emsearcy , la dernière fois, je pense que j'ai dû accidentellement me retrouver avec mon e-mail personnel. Ça a l'air bien maintenant !

(aussi, belle photo de profil)

Lorsque j'essaie de me connecter avec github pour vérifier mon CLA, j'obtiens une erreur d'accès refusé, puis lorsque j'essaie à nouveau, j'obtiens un accès refusé avec "Vous avez déjà enregistré cette identité". Existe-t-il un moyen de vérifier mon CLA ?

Oh ... et puis quand je regarde le lien "Détails" pour quelqu'un qui n'a pas signé le CLA, j'obtiens _mon_ CLA. Je m'attendrais à voir le statut CLA pour l'utilisateur en question.

Ayant également des problèmes avec la CNCF CLA. J'ai choisi un contributeur individuel et je n'ai pas pu changer l'e-mail qu'il a choisi pour moi, qui était un ancien e-mail professionnel, probablement extrait de github (heureusement, j'ai pu y accéder). Maintenant, je peux voir mon CLA signé mais je ne suis toujours pas marqué approuvé sur le PR.

Ayant également des problèmes, j'ai essayé de m'inscrire via GH qui avait un ancien e-mail comme principal, puis je me suis inscrit en utilisant un e-mail différent et je ne peux plus lier mon compte GH.

Il est clair que le CLAbot Linux Foundation (LF) n'est pas encore complètement cuit. Ce dont nous avons besoin en ce moment, c'est de l'aide d'un chef de produit pour analyser où les utilisateurs sont (parfois) coincés dans un cul-de-sac. Sur la base de cette analyse, nous examinerons s'il convient d'améliorer le LF CLAbot ou d'envisager des solutions alternatives (open source).

J'ai parlé avec @philips de la possibilité de fournir une assistance et j'espère avoir une mise à jour bientôt. Si quelqu'un d'autre veut aider à faire avancer ce progrès, n'hésitez pas à me contacter par e- mail .

En attendant, excusez-moi pour le retard.

@derekparker J'ai rencontré le même problème et j'ai fini par trouver la page d'édition du compte : https://identity.linuxfoundation.org/user/me/edit

La connexion via mon compte github, puis le changement manuel de l'e-mail sur mon CoreOS l'ont fait fonctionner. Je pense que j'ai dû passer par le workflow de réinitialisation du mot de passe pour pouvoir également modifier mes informations

@dankohn , je pense qu'une documentation solide sur l'inscription de l'entreprise,
inscriptions individuelles d'entreprise et dépannage commun de ces GH
serait un énorme début.

Le mardi 25 octobre 2016 à 20h24, Euan Kemp [email protected] a écrit :

@derekparker https://github.com/derekparker J'ai rencontré le même problème et
a fini par trouver la page de modification du compte : https://identity.
linuxfoundation.org/user/me/edit

Connexion via mon compte github, puis modification manuelle de l'e-mail en
mon CoreOS l'a fait fonctionner.


Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/27796#issuecomment -256239957,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAHxigmn_N1BhGJDqvbBLWoCyNxMbsZlks5q3sfXgaJpZM4I7IQL
.

Je suis le responsable de l'organisation Red Hat. Quand les gens me demandent ce qui ne va pas, je n'en ai généralement aucune idée. Je n'ai aucune idée de comment obtenir cette visibilité, mais si cela ne fonctionnait pas, je suis totalement perdu...

@caniszczyk @emsearcy Le webhook a échoué et aucun statut cncf-cla sur https://github.com/kubernetes/kubernetes/pull/35581. Pourriez-vous vérifier cela ?

@dankohn J'envoie actuellement un e-mail à des personnes potentielles avec lesquelles nous pourrions travailler ; et j'ai besoin d'écrire le document des exigences du produit. J'espère le faire par EOW.

@foxish Avons-nous désactivé le Google CLAbot dans le repo kubernetes ?

@ bgrant0607 Non, nous n'avons pas fait cela. Nous ne le désactiverons à l'échelle de l'organisation qu'une fois que nous aurons le bot mungegithub CNCF basé sur des webhooks. Bloqué par https://github.com/kubernetes/contrib/issues/1834

J'aimerais que les mesures de contribution des entreprises soient vérifiables indépendamment par différents groupes.
Il semble que le processus CLA soit une excellente fonction de forçage qui peut être utilisée pour aider à maintenir une carte des contributeurs individuels et de leurs affiliations corporatives (au fil du temps).

J'ai décrit un format pour ces divulgations CLA demandées dans ce numéro : https://github.com/kubernetes/contrib/issues/1972

Nous sommes prêts à basculer en gate sur le CNCF CLA d'ici la fin de la semaine. Nous enverrons de la documentation, des FAQ, etc. cette semaine avant de terminer la transition.
Le problème de blocage jusqu'à présent était : https://github.com/kubernetes/contrib/issues/1834 , qui est maintenant corrigé.

cc @dims @soltysh @sarahnovotny

merci beaucoup @foxish

Le déploiement est maintenant terminé et les organisations kubernetes et kubernetes-incubator utilisent la CNCF CLA.

@emsearcy @caniszczyk Pourriez-vous s'il vous plaît jeter un œil à https://github.com/kubernetes/kubernetes/pull/35672 ? L'auteur dit qu'il a signé la cla mais le statut dit toujours qu'il ne l'a pas fait.

@emsearcy J'ai également rencontré un problème https://github.com/kubernetes/kubernetes/pull/37640#issuecomment -263760417

A part: je regarde les options open source pour la gestion CLA afin que nous puissions creuser et résoudre ces problèmes sans être un SPOF sur @emsearcy. Rien dans le commerce ne correspond au moule ATM.

PTAL, @emsearcy ou @caniszczyk -- une autre employée de deis @michelleN a des problèmes avec CLAbot reconnaissant son CCLA.

Question d'utilisateur :
Puis-je signer la CCT CNCF en tant que salarié et en tant que particulier ?

Je vais regrouper les questions comme celle-ci et mettre à jour la FAQ afin que nous n'ayons pas à intervenir manuellement si souvent.

Pour compléter le commentaire précédent :

J'ai déjà signé le CLA en tant qu'individu en utilisant ce compte Github et mon e-mail personnel. Maintenant, mon employeur a signé la CLA et je veux pouvoir contribuer en utilisant le même compte Github, qui a également enregistré l'adresse e-mail de mon employé.

Lorsque je clique pour m'inscrire en tant qu'employé, j'obtiens le message suivant :

Le système n'a pas été en mesure de vous associer à une organisation ayant signé un accord de licence de contributeur d'entreprise pour ce projet. Veuillez vous assurer que vous utilisez l'adresse e-mail de votre organisation sur votre profil, contactez quelqu'un au sein de votre organisation qui est responsable de la supervision des collaborateurs autorisés pour ce projet, ou utilisez le formulaire de contact ci-dessous.

Mon profil Linux Foundation contient mon ensemble d'e-mails personnels et il ne semble pas y avoir de moyen d'ajouter plusieurs e-mails.

J'ai aussi des problèmes. Mon entreprise a signé le CCLA. Mon ID LF indique que je fais partie du groupe des Contributeurs CNCF. Mais je ne peux pas lier mon identité LF à mon identité github. J'obtiens l'erreur "Cette identité est enregistrée pour un autre utilisateur" lorsque j'essaie de lier LF Id à github Id. J'utilise différents e-mails pour LF (entreprise) et Github (personnel). Probablement un problème d'identifiant LF, mais peut-être que d'autres ont rencontré ce problème.

Bloqué sur ma demande d'extraction k8s.

Dans le référentiel kubernetes/helm, quelque part dans le processus avant de créer un PR, j'ai été dirigé vers le formulaire Google CCLA. Après avoir créé le PR, le bot LF CLA est arrivé et m'a dirigé vers le formulaire CNCF CCLA.

Vous devez probablement corriger ce premier lien, car il cause de la confusion et du travail supplémentaire pour les gestionnaires (ce qui est rarement une bonne chose :)).

Suite à mon précédent commentaire :

J'ai décidé de créer un compte GitHub séparé et de l'utiliser pour mon CLA d'entreprise. J'ai supprimé mon adresse e-mail professionnelle de mon compte personnel et je l'ai utilisée pour mon nouveau compte (https://github.com/yissacharcw).

Mon organisation m'a alors envoyé une invitation à rejoindre la Fondation Linux. J'ai suivi le lien et je me suis connecté en utilisant mon nouveau compte GitHub. J'ai rempli les informations de création de compte et j'ai essayé de créer un compte, mais j'ai reçu l'erreur que mon e-mail était déjà utilisé. Cela ne devrait pas être le cas, étant donné que je n'ai pas encore utilisé cet e-mail pour créer un compte. Je ne vois aucune indication sur mon compte personnel que l'e-mail de l'entreprise y est utilisé. Il n'y a aucune information sur la façon de réclamer cet e-mail pour l'utiliser.

Je suis maintenant coincé dans le fait que je n'ai aucun moyen d'enregistrer mon courrier électronique d'entreprise pour un compte Linux Foundation.

Veuillez envoyer un e-mail à [email protected] pour recevoir une assistance concernant les identifiants Linux Foundation ou la signature de CLA. Nous aurons besoin d'informations telles que les adresses e-mail utilisées que nous ne voudrions pas demander ici, et il est difficile de suivre les demandes individuelles dans un seul fil. L'utilisation des formulaires de contact dans toutes les "impasses" du processus de signature CLA créera également un ticket d'assistance auprès de la Linux Foundation.

Quelques commentaires sur ce qui précède pour la postérité :

Vous ne devriez pas avoir besoin d'un deuxième identifiant Linux Foundation pour contribuer "en tant qu'employé" plutôt qu'en tant qu'individu. Vous pouvez être associé à une organisation soit par le responsable CCLA de votre organisation qui vous envoie une invitation, soit, si activé par le responsable de votre CCLA, en faisant correspondre l'adresse e-mail de l'entreprise. Vous devrez modifier temporairement l'adresse e-mail sur votre profil Linux Foundation ID pour faire ce dernier s'il ne s'agit pas actuellement de l'adresse de votre organisation ("Veuillez vous assurer que vous utilisez l'adresse e-mail de votre organisation sur votre profil").

Suite à une invitation à rejoindre une organisation, vous pouvez vous connecter à votre compte Linux Foundation ID existant.

Vous ne pouvez pas associer votre compte GitHub à plusieurs identifiants Linux Foundation.

Les statuts non mis à jour semblent être un bogue : par exemple, à chaque mise à jour vers 37640, notre bot lfcla (un service Web autonome qui reçoit les notifications Github et met à jour les PR en fonction du statut de l'utilisateur dans le système LF CLA) a essayé de définir un "philips autorisé " cla/linuxfoundation state=success notification d'état sur les commits, qui selon la fonction go-github s'exécute avec succès, sauf que Github ne l'enregistre pas réellement. Je vais regarder ça.

J'obtiens également l'erreur "Cette identité est enregistrée pour un autre utilisateur". comme @hasahni. Au départ, l'e-mail LF était personnel (je me suis inscrit en tant que contributeur individuel) et l'e-mail Git avait l'e-mail de mon entreprise comme adresse principale. J'ai changé mon e-mail Git, mais j'obtiens toujours la même erreur.

J'ai envoyé un e-mail à l'adresse @emsearcy publiée ci-dessus, et ils ont pu résoudre mon problème en dissociant l'e-mail de mon entreprise du compte auquel il était lié. J'ai ensuite pu créer un compte Linux Foundation avec le compte GitHub de ma société et l'adresse e-mail de ma société.

Comme mentionné ci-dessus, c'est plus facile si vous n'utilisez qu'un seul compte. Si vous revenez à https://identity.linuxfoundation.org/projects/cncf vous pouvez choisir "Employé" si vous avez choisi "Individuel" auparavant, et vice-versa. Le responsable de votre organisation peut vous retirer de l'organisation à une date ultérieure si vous ne devez plus être autorisé par cette organisation.

Les identifiants Linux Foundation peuvent être associés à des connexions à divers sites Web de projets LF, à des propositions de conférence et à nos certifications d'administrateur système (qui devraient rester avec vous lorsque vous changez d'entreprise), de sorte que le compte devrait être davantage un "vous appartient/suit". votre configuration. (Similaire à la façon dont vous signalez tous ce problème, vous n'avez probablement qu'un seul compte GitHub que vous utilisez !)

Nous voyons beaucoup de gens qui continuent de s'opposer à la CLA.

Le code source du bot CLA est-il open source (et si oui, où se trouve le référentiel), afin que nous puissions essayer d'améliorer le flux ? Ou des captures d'écran sont-elles disponibles (en particulier pour la version individuelle) ?

_Quelque chose_ pousse manifestement les gens à abandonner l'entonnoir. J'ai tout de suite remarqué que je pouvais me connecter avec un compte non-github, mais j'ai ensuite dû me connecter avec github pour lier un compte github. Malheureusement, je n'ai pas de deuxième compte github, donc c'était tout ce que j'avais. Mais il y a certainement des fruits à portée de main.

D'autres pensées:

  • Existe-t-il une politique stricte de non-spam sur l'utilisation de l'adresse e-mail, évidemment liée ?
  • L'identifiant Linux Foundation est-il par défaut mon adresse e-mail ?

Le LF CLAbot n'est pas open source, et ne le sera pas, car (malgré le bon travail de @emsearcy) c'est une boule de poils, notamment en termes de stockage backend. Au nom de la CNCF, je tiens à m'excuser pour les problèmes rencontrés par les gens. La meilleure solution à court terme pour les problèmes de connexion consiste à envoyer un e-mail à [email protected] car ils sont assez réactifs, mais uniquement pendant les heures ouvrables de PT.

La solution à long terme étudiée par @philips consiste à travailler avec l'un des CLAbots open source et à passer un contrat avec l'un de leurs principaux développeurs pour apporter les modifications nécessaires à Kubernetes et également pour obtenir ces modifications en amont. J'espère que nous aurons des progrès sur ce front en janvier.

Je ne pense pas que ce soit un problème avec CLAbot autant que le fait que le CLA soit requis en premier lieu. Lorsqu'un utilisateur a une fonctionnalité importante à laquelle il essaie de contribuer en amont, il est susceptible de la supporter et de passer par le processus CLA. Mais lorsque l'utilisateur ne fait que contribuer à une simple correction de documentation ou à une petite correction de bogue, il est probable qu'il renonce simplement.

Considérez le problème que @justinsb vient de créer : l'utilisateur contribue littéralement à un correctif de document à un seul caractère. Et pour cela, ils se retrouvent avec une CLA qui les oblige à entrer leurs informations et un accord légal. Ce n'est pas étonnant qu'ils veuillent renflouer.

Je sais d'après ma propre expérience personnelle que j'ai résisté à la contribution de correctifs de documentation pendant un certain temps car je ne voulais pas avoir à traiter avec la CLA. Ce n'est que lorsque j'ai eu une fonctionnalité que je voulais vraiment ajouter que j'ai eu le souci de signer le CLA.

Je ne sais pas si c'est légalement faisable, mais je pense vraiment que les soumissions sans code ne devraient pas être soumises à la CLA (ce serait également idéal si les changements de code triviaux n'étaient pas soumis à la CLA, mais je me rends compte que cette ligne est plus difficile à dessiner que code/non-code).

Je comprends la nécessité pour le projet Kubernetes de se protéger légalement, mais pousser la CLA sur des changements insignifiants décourage activement les PR intempestifs qui sont si courants dans les projets GitHub.

Il me semble également un peu absurde que si l'utilisateur venait d'ouvrir un problème à la place ("La documentation devrait indiquer us-east-2 non us-east-1 "), il n'y aurait pas d'interaction CLAbot et quelqu'un ferait juste le changement pour eux.

De plus, puisque je suis conscient du problème maintenant, après avoir vu le PR, je peux aller de l'avant et soumettre le correctif moi-même (à moins que vous ne me disiez que cela va à l'encontre de la CLA, ce que je trouverais encore plus surprenant !).

Sur la base des retours de plusieurs projets actuels et potentiels, la CNCF a modifié sa charte le mois dernier pour permettre à chaque projet hébergé de déterminer s'il souhaite ou non un CLA ( fil long avec contexte). Cependant, je pense qu'il est très peu probable étant donné que Kubernetes est maintenant l'un des projets logiciels les plus rapides de l'histoire que les responsables décident d'abandonner le CLA. Si vous voulez les encourager à le faire, je vous suggère d'ouvrir un nouveau sujet.

Pour l'instant, nous supposons que l'exigence CLA restera (et aussi que la CNCF aura probablement de nouveaux projets avec des CLA), nous voulons donc un CLAbot qui cause le moins de frictions possible.

Pour votre information, OpenStack a eu ce même problème avec l'exigence d'un ICLA/CCLA pendant longtemps. « Nous » nous dirigeons vers le DCO :
https://wiki.openstack.org/wiki/OpenStackAndItsCLA#The_Proposal

Salut!

J'essaie de signer le CLA mais je suis bloqué à l'étape "valider l'e-mail". Je n'ai pas reçu d'e-mail (spam vérifié et partout) après que le code de validation devait m'être envoyé. J'ai attendu 5 heures donc j'ai l'impression qu'il ne viendra pas. J'ai également essayé le bouton "renvoyer la vérification" plusieurs fois et cela ne m'a pas non plus envoyé de code.

Mon email github (l'autorisation que j'ai choisie lors de la configuration du compte linuxfoundation) est le bon email.

Je ne suis pas sûr du bon endroit pour poser cette question, mais la FAQ CLA m'a dit de venir ici si j'avais des problèmes.

Merci!

Excuses. Veuillez envoyer un e-mail au service d'assistance de Linux Foundation <
[email protected]>.

Le mercredi 18 janvier 2017 à 13h23, khalpin11 [email protected] a écrit :

Salut!

J'essaie de signer le CLA mais je suis bloqué à l'étape "valider l'e-mail". je
n'ont pas reçu d'e-mail (spam vérifié et partout) après le
code de validation devait m'être envoyé. j'ai aussi essayé le
bouton "renvoyer la vérification" plusieurs fois et cela ne m'a pas envoyé de
code non plus.

Je ne suis pas sûr du bon endroit pour poser cette question, mais la FAQ CLA m'a dit de
venez ici si j'ai des problèmes.

Merci!


Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/27796#issuecomment-273605799 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AC8MBlgbtF51VU6H50t-IT3_PFEDyOn3ks5rToLQgaJpZM4I7IQL
.

--
Dan Kohn [email protected]
Directeur Exécutif, Cloud Native Computing Foundation https://cncf.io/
tél. :+1-415-233-1000

Salut - J'ai essayé de m'inscrire en tant qu'employé Heptio mais le système n'a pas pu me vérifier. S'il vous plaît aidez-moi! Merci.

@skriss Veuillez envoyer un e-mail au Helpdesk de la Linux Foundation [email protected] avec votre e-mail et votre nom d'utilisateur GitHub.

J'essaie d'enregistrer le CERN auprès de la CNCF CLA.

J'ai créé une CCT CNCF pour le "test" de l'entreprise afin d'obtenir une copie de l'accord à examiner avec notre équipe juridique. Malheureusement, je ne peux plus enregistrer le CERN en tant qu'organisation.

Pouvez-vous supprimer l'entreprise "test" que j'ai enregistrée et me remettre à l'état de ne pas être connu du système. Mon e-mail est tim. [email protected].

@ noggin143 Vous devez envoyer votre demande par e-mail à [email protected] et ils vous aideront.

J'ai essayé de signer la CNCF CLA, mais j'ai toujours des problèmes. J'aurais également dû être enregistré comme contact officiel de la Fondation OpenStack pour approuver d'autres contributeurs. J'ai également déposé un ticket auprès du helpdesk. Merci Chris

@hogepodge , veuillez envoyer un e-mail à [email protected] pour résoudre ce problème. (Notez que le fait d'être enregistré en tant que contact ne vous met pas automatiquement dans le groupe CLA.)

J'ai signé CNCF CLA. Mon commit est https://github.com/honkiko/kubernetes/commit/38b95f0c38f46303e7b091e56a70a515a8c4706c.patch , dans lequel " [email protected] " est présent. Et j'ai ajouté cet e-mail à la liste de diffusion de mon compte github.
Mais ma pull request (https://github.com/kubernetes/kubernetes/pull/42232) est toujours dans l'état "cncf-cla: no".

@honkiko Tencent n'a pas encore signé le CLA d'entreprise :

https://identity.linuxfoundation.org/node/463

Si vous avez une copie du CCLA signé, vous pouvez me l'envoyer à [email protected] ou à [email protected]

D'un coup d'œil rapide, on dirait que " [email protected] " a essayé de le signer mais n'a jamais fini.

J'ai soumis un PR et l'auteur du commit a utilisé mon e-mail principal qui s'est connecté au Github, mais pourquoi le CLA a-t-il été envoyé à mon e-mail public jusqu'au bout ? Même si j'ai changé l'adresse e-mail publique en mon adresse e-mail principale, le CLA est toujours envoyé à l'adresse e-mail précédente ? comment le résoudre?

J'ai essayé de m'inscrire en tant que particulier, mais le lien https://identity.linuxfoundation.org/projects/cncf mène à une page introuvable.

@sdomula J'ai ouvert un ticket urgent avec la Linux Foundation à résoudre. Je posterai à nouveau quand ce sera corrigé.

@sdomula Ceci est maintenant résolu. Nous enquêtons sur la cause du temps d'arrêt. Désolé pour le tracas.

Page introuvable : https://identity.linuxfoundation.org/projects/cncf

Si j'ai raison, la bonne URL est maintenant : https://identity.linuxfoundation.org/node/285/

À droite ?

Ressemble à une mauvaise poussée de configuration.

/cc @caniszczyk

Réescalade maintenant.

Et ça remonte. Nous ajouterons notre enquête sur ce temps d'arrêt à l'autre enquête.

Salut à tous, j'ai du mal à satisfaire le cla-bot pour https://github.com/kubernetes/charts/pull/766. Je pense que c'est parce que je me suis inscrit en tant que " [email protected] " alors que mes commits git sont sous " [email protected] ". Depuis, j'ai changé mon e-mail Linux Foundation pour qu'il corresponde à mes commits git, mais je n'arrive pas à générer un nouveau CLA sous le nouvel e-mail. S'il vous plaît, arrêtez.

@jpoon , veuillez envoyer un e-mail à [email protected]

Ça ira. Merci @dankohn

Bonjour, j'ai du mal à passer le contrôle cla sur https://github.com/kubernetes/helm/pull/2143 et pour autant que je sache, j'ai fait tout ce dont j'avais besoin pour que l'e-mail soit correctement défini, le formulaire est signé et ainsi de suite. Quelqu'un peut-il aider s'il vous plaît pourquoi le cla ne passe pas? Merci.

@dankohn J'ai envoyé un e-mail à [email protected] et la dernière réponse date d'il y a une semaine. Je ne sais pas vraiment comment résoudre ce problème....

@jpoon s'excuse pour le problème. Pourriez-vous s'il vous plaît renvoyer au service d'assistance avec un cc à caniszczyk à linuxfoundation.org

J'ai demandé un e-mail deux fois. Seul le premier est arrivé, et il est maintenant expiré. Le deuxième n'est jamais arrivé. Échec la troisième fois aussi.

@TheStalwart Avez-vous envoyé un e-mail au service d'assistance ?

Après une nouvelle tentative, j'ai pu signer via le lien qui avait précédemment expiré. Yay!

J'ai du mal à satisfaire la vérification cla pour https://github.com/kubernetes/test-infra/pull/2450 . Je me suis inscrit en tant qu'employé de Google en utilisant mon compte github et j'ai utilisé le même e-mail que celui que j'utilise pour mes commits. J'ai reçu un e-mail demandant de vérifier mon adresse e-mail et depuis lors, le site linuxfoundation indique que je me suis inscrit correctement. Cependant, ma pull request a toujours le drapeau "cnfc-cla: no", même après avoir laissé des commentaires supplémentaires sur le PR. J'apprécierais toute aide que je peux obtenir sur cette question. Merci!

Je vois la même chose sur plusieurs PR.

@spxtr pouvez-vous indiquer les relations publiques pertinentes ?

En outre, je vous recommande d'envoyer un e-mail à "Linux Foundation Helpdesk [email protected] " si vous rencontrez des problèmes CLA.

La plupart du temps, c'est parce que vous n'avez pas l'e-mail correspondant répertorié dans les paramètres de votre profil GitHub ou que vous ne vous êtes pas entièrement connecté à https://identity.linuxfoundation.org/projects/cncf et que vous avez lié votre profil GitHub avec le Système BF.

J'ai du mal à satisfaire la vérification cla pour kubernetes/test-infra#2450 . Je me suis inscrit en tant qu'employé de Google en utilisant mon compte github et j'ai utilisé le même e-mail que celui que j'utilise pour mes commits. J'ai reçu un e-mail demandant de vérifier mon adresse e-mail et depuis lors, le site linuxfoundation indique que je me suis inscrit correctement. Cependant, ma pull request a toujours le drapeau "cnfc-cla: no", même après avoir laissé des commentaires supplémentaires sur le PR. J'apprécierais toute aide que je peux obtenir sur cette question. Merci!

Idem ici, sauf que j'ai signé en tant que contributeur individuel, en utilisant exactement le même e-mail que GitHub (en utilisant GitHub Login). Essayez quand même de découvrir ce qui n'allait pas.
J'écrivais au Helpdesk de la Linux Foundation, jusqu'à présent, je n'ai eu aucune réponse de leur part.

https://github.com/kubernetes/kubernetes/pull/44727 Soumettre la file d'attente - PR manque l'étiquette CLA ; nécessite l'un des cla : oui, cncf-cla : oui ou cla : approuvé par l'homme

Je pense avoir tout fait...

J'ai essayé de m'inscrire en tant qu'individu ( gh<at>purefiction.net ), mais après environ 4 heures, je n'ai toujours pas reçu d'e-mail de confirmation de la part de la CNCF. Rien dans le dossier spam.

@atombender Inscrivez-vous sur hellosign avec la même adresse e-mail et vous y trouverez peut-être le document d'accord. Malheureusement, il n'y a pas d'option re-send agreement .

@dolftax : Qu'est-ce que "hellosign" et comment y accéder ? Cette adresse e-mail n'est pas celle que j'utilise pour créer des commits, donc je dois la changer, mais cela ne me laissera pas recommencer le processus.

@dolftax : J'ai pu aller plus loin en supprimant les cookies et en passant par la création de compte ici . Cependant, rien d'autre ne se passe. Si je reviens ensuite sur ce même lien, j'obtiens une page disant:

Un contrat de licence de contributeur a été envoyé à votre adresse e-mail. Celui-ci doit être signé électroniquement pour terminer le processus d'inscription des contributeurs.

... mais pas d'e-mail.

@atombender @dolftax veuillez envoyer un e-mail à [email protected] et ils pourront vous aider avec vos problèmes. Nous évaluons également comment modifier les messages d'erreur pour rendre l'étape suivante plus claire lorsque l'e-mail n'arrive pas.

Notre service d'assistance assurera le suivi de votre ticket, mais pour les remarques générales : HelloSign (notre fournisseur de signature électronique qui envoie les e-mails d'accord) envoie des rappels à 3 et 7 jours. Notre service d'assistance peut également envoyer un rappel manuellement, même s'il ne s'agit pas d'une fonctionnalité présente dans l'interface utilisateur.

Quant au commentaire sur l'inscription à Hellosign (merci pour la suggestion @dolftax !), ce serait d'aller sur https://www.hellosign.com/ et de cliquer sur "S'inscrire". Un compte gratuit vous permet d'envoyer jusqu'à 3 documents par mois, sans compter les documents qui vous sont envoyés par d'autres personnes (qui sont normalement signés sans création de compte côté HelloSign).

(Je vois un accord en attente du "côté" HelloSign pour l'e-mail "gh". Leur notification sortante n'a pas rebondi non plus, sinon cela me le dirait.)

@dankohn : est-ce un problème courant que les utilisateurs ne reçoivent pas d'e-mails, où il n'y a pas de fautes de frappe ou de problème similaire ? Nous pouvons contacter l'assistance HelloSign et voir s'ils peuvent fournir un dépannage au cas par cas.

@dankohn Renvoyer l'accord de l'interface utilisateur linuxfoundation serait bien mieux.

J'ai signé le CLA, mais toujours le drapeau "cnfc-cla: non", veuillez jeter un œil @foxish @sarahnovotny

J'ai un problème avec le CLA, https://github.com/kubernetes/test-infra/pull/2764
J'ai confirmé l'utilisation du bon e-mail, connecté CNCF en tant qu'individu, l'ai lié à github et google, et fait un autre commit par la suite, j'ai toujours une erreur sur CLA, pourriez-vous s'il vous plaît jeter un coup d'œil ?

@yutongz pouvez-vous envoyer un e-mail à Linux Foundation Helpdesk [email protected] avec votre problème, assurez-vous que votre identifiant github est lié à https://identity.linuxfoundation.org/projects/cncf et vos commits

@sarahnovotny et @foxish
J'ai des problèmes avec la signature du CLA

J'ai signé en tant qu'[email protected] et je ne peux pas signer avec [email protected] (e-mail github principal) donc j'ai un problème sur github comme celui-ci : https://github.com/kubernetes/contrib/pull /2548 (toujours en attente de ma signature sur CLA)

J'ai envoyé un mail à Linux Foundation il y a un mois, mais je suis toujours bloqué...
Peux-tu le réparer ?

@naarani Toutes mes excuses pour le problème. Je vais escalader cela avec LF IT.

La vérification de licence pour https://github.com/kubernetes/community/pull/631 échoue, pourtant mon profil (voir pièce jointe) semble me mettre sous le groupe CNCF :

Profile Screenshot

Mon email à https://identity.linuxfoundation.org/user/me/edit est le même que celui que j'ai utilisé lors du commit.

Y a-t-il quelque chose que je puisse faire pour résoudre ce problème ? Merci beaucoup!

Ce groupe s'affiche également pour les CLA non signés (en attente).

Merci. Il est probable que je n'ai pas signé à ce moment-là.

J'attends l'e-mail depuis un moment maintenant, et je ne l'ai pas reçu... j'ai vérifié les spams et tout. De plus, je ne semble pas recevoir de copies des messages avec "Envoyez-moi une copie" coché, donc cela pourrait très bien être un problème de délivrabilité. J'utilise FastMail. Existe-t-il une page Web ou un autre moyen de signer l'accord ?

@wyc : oui, un autre utilisateur de Fastmail ne recevait pas non plus d'e-mails. Nous avons attribué le problème au fait que Fastmail n'accepte pas les e-mails de HelloSign, notre fournisseur de signature électronique, avec la réponse suivante du serveur de messagerie (fournie par HelloSign, car il s'agit de leur adresse IP) :
451 4.7.1 Data command rejected: Host<br i="7"/> 198.61.255.111/do255-111.hellosign.com has exceeded the per-day email<br i="8"/> limit of 40, try again later - helo=<do255-111.hellosign.com i="9"> - RLR001<br i="10"/> </do255-111.hellosign.com>
Seriez-vous en mesure de faire un suivi auprès de Fastmail et de leur faire savoir que cette limite de 40 jours par adresse IP (me semble vraiment faible...) affecte votre capacité à accepter les e-mails de ce fournisseur de services légitime ?

Ci-dessus, il a été suggéré par un autre utilisateur ci-dessus que si vous vous connectez/enregistrez sur www.hellosign.com , vous devriez pouvoir voir la demande de signature électronique en attente (bien que je n'aie pas essayé cela pour confirmer que cela fonctionne) . À moins que vous n'ayez une identité Google avec cet e-mail, en fournissant un e-mail validé via SSO, vous devrez probablement pouvoir recevoir un e-mail initial de validation de compte de HelloSign ... et nous aurons alors de nouveau besoin de Fastmail pour arrêter sévèrement le taux -limiter HelloSign.

D'accord, @emsearcy , cela a fonctionné comme un charme. Merci. Je vais contacter mon fournisseur de messagerie et essayer de les amener à résoudre ce problème.

J'ai fait un petit article à ce sujet ci-dessous que nous pouvons, espérons-le, ajouter à https://github.com/kubernetes/kubernetes/wiki/CLA-FAQ

Parce que GitHub Wiki n'autorise pas actuellement les contributions extérieures, ci-dessous compte comme une contribution basée sur la licence que je viens de signer :)

Je ne reçois pas d'e-mail contenant le CLA pour les accords de contributeur individuel.

@emsearcy explique dans
https://github.com/kubernetes/kubernetes/issues/27796#issuecomment -303234338
que certains utilisateurs de certains fournisseurs de messagerie (à savoir FastMail) rencontraient
problèmes de délivrabilité avec les e-mails du fournisseur de signature électronique, HelloSign. Jusqu'à ce
est corrigé, la solution de contournement suivante est disponible :

  1. Créez un compte sur HelloSign en utilisant le même email pour le CLA.
  2. Accédez à la section "Documents" à l'aide de la barre de navigation de gauche et appuyez sur la touche
    Bouton "Signer" pour "Contrat de Licence Contributeur Individuel CNCF".
    HelloSign Documents Section
  3. Révisez et signez, si vous le souhaitez.
    HelloSign Signing Page
  4. Confirmez que l'accord a été signé dans la section "Documents".
    HelloSign Documents Section Confirmed
  5. Si vous avez un PR existant avec cncf-cla: no , attendez 5 minutes pour HelloSign
    et les serveurs CI pour résoudre le nouvel accord. Laisser un nouveau commentaire sur
    PR, et le libellé cncf-cla: no devrait devenir un cncf-cla: yes .
    CLA Fixed

Réduction:

### I'm not getting an email containing the CLA for Individual Contributor Agreements.

<strong i="40">@emsearcy</strong> explains in
https://github.com/kubernetes/kubernetes/issues/27796#issuecomment-303234338
that some users of certain email providers (namely FastMail) were experiencing
deliverability issues with emails from the e-signing vendor, HelloSign. Until this 
is redressed, the following workaround is available:

1. Create an account on [HelloSign](https://hellosign.com) using the same email for the CLA.
2. Go to the "Documents" section using the left navigation bar and press the
   "Sign" button for "CNCF Individual Contributor License Agreement".
   ![HelloSign Documents Section](https://i.imgur.com/n6o6KzO.png)
3. Review and sign, if desired.
   ![HelloSign Signing Page](https://i.imgur.com/Tcyms6C.png)
4. Confirm that the agreement has been signed in the "Documents" section.
   ![HelloSign Documents Section Confirmed](https://i.imgur.com/99QWSNu.png)
5. If you have an existing PR with `cncf-cla: no`, wait 5 minutes for HelloSign
   and the CI servers to resolve the new agreement. Leave a new comment on the
   PR, and the `cncf-cla: no` label should become a `cncf-cla: yes`.
   ![CLA Fixed](https://i.imgur.com/pKhLQH5.png)

Merci @wyc ! Mise à jour de la FAQ.

Salut,

J'ai essayé de signer la CLA au nom de mon entreprise. Je me suis inscrit sur Github et j'ai ajouté les détails de l'entreprise. Le CLA qui a été généré contient cependant mon e-mail personnel. Je suis allé créer un autre compte avec l'e-mail de mon entreprise et je l'ai invité en tant que responsable de l'organisation. Est-il possible de re-déclencher la génération afin qu'elle ait l'e-mail de mon entreprise dans le document ? L'adresse e-mail de mon entreprise est adam[@]iflix.com, et mon adresse personnelle est adam[@]boxxen.org

Salut! Je souhaite inscrire ma nouvelle organisation (logiciel blackduck) en tant que contributeur kubernetes - cependant, mon compte github actuel est lié à mon organisation précédente (red hat). Comment puis-je (1) détacher mon CLA et (2) créer un nouveau CLA pour une organisation qui ne s'est pas encore engagée envers kubernetes ? Merci !

Je viens de t'expulser du RH CLA. Je ne sais pas comment cela aurait pu être fait en libre-service.

merci eric :) je suppose que j'étais à mi-chemin.

Après avoir été supprimé de l'organisation, vous pouvez créer une nouvelle organisation sur https://identity.linuxfoundation.org/node/285/organization-signup

Ce message a été créé automatiquement par le logiciel de distribution de courrier.

Un message que vous avez envoyé n'a pas pu être remis à un ou plusieurs de ses
destinataires. Il s'agit d'une erreur temporaire. La ou les adresse(s) suivante(s) différée(s) :

curtis.l. [email protected]
Le domaine imwiz.com a dépassé le nombre maximum d'e-mails par heure (168/150 (112%)) autorisé. Le message sera réessayé plus tard

------- Ceci est une copie du message, y compris tous les en-têtes. ------
Reçu : de o5.sgmail.github.com ([192.254.113.10]:45396)
par box969.bluehost.com avec esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)
(Exim 4.87)
(enveloppe-de)
identifiant 1dGU7y-000QH7-Mz
pour [email protected] ; jeu. 01 juin 2017 11:43:21 -0600
Signature DKIM : v=1 ; a=rsa-sha1 ; c=détendu/détendu ; d=github.com ;
h= from:reply-to :to:cc:in-reply-to:r eferences:subject :mime- version:content-type :content-transfer- encoding:list-id :list- archive:list-post :list -Se désabonner;
s=s20150108 ; bh=ia3KtOMIWMbpcYNB7BF47jscgOE= ; b=wrEnOf0+m7yWRmnA
HmbxqBgRZalVLCr9ltrAzRO0Xo9B5hetAXIRGt+KoyYjST6dnSVJZf2qr2c/ywsz
ibzt+VpXLS2N/ktdMhBLy25RzMe/UZzT2Ak1rA4JVgQwI8bW+XUTk3Wf1XW2mLev
aqgwhD/qyryuCJhunLBhqxJztrI=
Reçu : par filter0654p1mdw1.sendgrid.net avec l'identifiant SMTP filter0654p1mdw1-19843-5930522A-4
2017-06-01 17:43:06.164526033 +0000 UTC
Reçu : de github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16])
par ismtpd0002p1iad1.sendgrid.net (SG) avec l'identifiant ESMTP 8eFn2zRFThqa_B9E8cA5dw
pour [email protected] ; jeu. 01 juin 2017 17:43:06.085 +0000 (UTC)
Date : Jeu, 01 juin 2017 10:43:05 -0700
De : Eric Searcy [email protected]
Répondre à : kubernetes/kubernetes [email protected]
À : kubernetes/kubernetes [email protected]
Cc : Abonné [email protected]
ID du message:
En réponse à:
Les références:
Objet : Re : [kubernetes/kubernetes] Passage à la Linux Foundation (CNCF) CLA
système (#27796)
Version Mime : 1.0
Type de contenu : multipart/alternatif ;
limite="--==_mimepart_59305229e47b9_383e3fe2b5315c2c56015" ;
jeu de caractères=UTF-8
Encodage de transfert de contenu : 7 bits
Priorité : liste
X-GitHub-Sender : emsearcy
Destinataire X-GitHub : falenn
X-GitHub-Reason : abonné
ID de liste : kubernetes/kubernetes
Liste-Archive : https://github.com/kubernetes/kubernetes
Liste-Post : [email protected]
Liste-désinscription :,
https://github.com/notifications/unsubscribe/AAq2CmYSYGSFsTnGNPIQM8XWSlg0u0-Cks5r_vgpgaJpZM4I7IQL
X-Auto-Response-Suppress : Tout
X-GitHub-Recipient-Address : [email protected]
X-SG-EID : APO41b8ovafPb3SK9rw3vNpc43NX8G/TIzmCUdtslW4MQwNXMLF1riQs5qL7Y2+n37CaeU19Lg72gH
pHediivQ8KuR0LkwdWDe2kalBL0uG3dmE1PZ4RXmc6VDFQRVH7wlG6Wc+wEcvscrXWEuXWCfCL+wOA
x5j/wGGY22HSrKDO211vnPTM3DVM/DsqL9WZDrgs4GyV2tnQ5+HKVxrY8g==
Statut X-Spam : Non, score=-2,5
X-Spam-Score : -24
X-Spam-Bar : --
X-Ham-Report : Logiciel de détection de spam, fonctionnant sur le système "box969.bluehost.com",
n'a PAS identifié cet e-mail entrant comme spam. L'original
un message a été joint à ceci afin que vous puissiez le voir ou l'étiqueter
futur e-mail similaire. Si vous avez des questions, consultez
root @localhost pour plus de détails.

Aperçu du contenu : après avoir été supprimé de l'organisation, vous pouvez
créer une nouvelle organisation sur https://identity.linuxfoundation.org/node/285/organization-signup
-- Vous recevez ceci parce que vous êtes abonné à ce fil. Répondre
directement à cet e-mail ou consultez-le sur GitHub : https://github.com/kubernetes/kubernetes/issues/27796#issuecomment -305567241
[...]

Détails de l'analyse de contenu : (-2,5 points, 4,0 requis)

description du nom de la règle pts


-0.0 RP_MATCHES_RCVD Le domaine de l'expéditeur de l'enveloppe correspond au domaine du relais de transfert
-2.8 RCVD_IN_MSPIKE_H2 RBL : Réputation moyenne (+2)
[192.254.113.10 répertorié dans wl.mailspike.net]
-0.0 SPF_PASS SPF : l'expéditeur correspond à l'enregistrement SPF
1.3 HTML_IMAGE_ONLY_24 BODY : HTML : images avec 2 000 à 2 400 octets de mots
0.0 HTML_MESSAGE BODY : HTML inclus dans le message
-0.1 DKIM_VALID_AU Le message a une signature DKIM ou DK valide de l'auteur
domaine
-0.1 DKIM_VALID Le message a au moins une signature DKIM ou DK valide
0.1 DKIM_SIGNED Le message a une signature DKIM ou DK, pas nécessairement valide
-0,8 AWL AWL : Score ajusté de la réputation AWL de De : adresse
X-Spam-Flag : NON

----==_mimepart_59305229e47b9_383e3fe2b5315c2c56015
Type de contenu : texte/plain ;
jeu de caractères=UTF-8
Encodage de transfert de contenu : 7 bits

Après avoir été supprimé de l'organisation, vous pouvez créer une nouvelle organisation sur https://identity.linuxfoundation.org/node/285/organization-signup

--
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/kubernetes/kubernetes/issues/27796#issuecomment -305567241
----==_mimepart_59305229e47b9_383e3fe2b5315c2c56015
Type de contenu : text/html ;
jeu de caractères=UTF-8
Encodage de transfert de contenu : 7 bits

Après avoir été supprimé de l'organisation, vous pouvez créer une nouvelle organisation sur https://identity.linuxfoundation.org/node/285/organization-signup


Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion .


----==_mimepart_59305229e47b9_383e3fe2b5315c2c56015--

Je ne peux pas enregistrer après avoir modifié mon organisation, il y a une erreur You must select one or more groups for this content . Quelqu'un pourrait-il aider? Merci!

salut @supereagle votre meilleur pari est d'envoyer un email à [email protected]. (n'hésitez pas à me mettre en copie.

@wyc bon travail !

Existe-t-il un moyen de faire fonctionner la signature de l'accord lors de l'utilisation de l'adresse e-mail github noreply dans les commits ?
Voir https://help.github.com/articles/about-commit-email-addresses/

C'est une question pour [email protected]. Je crois que l'adresse e-mail est ce qui est utilisé pour l'identification CLA, donc c'est peu probable.

Nous considérons cela (adresses e-mail noreply) comme une demande de fonctionnalité, mais nous pouvons rencontrer des problèmes avec cela car de plus en plus de projets commencent à adopter DCO dans CNCF (qui nécessite un e-mail dans la signature Signed-Off-By).

J'ai signé le CLA comme documenté (avec le bon compte github et e-mail) et cela ne fonctionne pas pour ce PR : https://github.com/kubernetes/charts/pull/1578

Pour un dépannage au cas par cas, veuillez envoyer un e-mail à [email protected] si vous ne l'avez pas déjà fait.

En raison de l'exigence de la CNCF selon laquelle nous utilisons les adresses e-mail d'entreprise comme e-mail de récupération LF, j'ai été bloqué sur mon compte LF personnel. J'ai envoyé un e-mail au service d'assistance et ils m'ont recommandé de créer un nouveau compte LF.

J'ai 2 comptes Linux Foundation :

Mais:

  1. Je dois signer le CLA avec la deuxième adresse.
  2. Pour signer la CLA, le compte doit être associé à un compte GitHub.
  3. Je ne peux pas le faire, car mon compte GitHub est déjà associé à mon compte personnel LF/signature CLA.

Aucune suggestion?

"Idem", presque. Mon compte GitHub a deux adresses e-mail vérifiées, primaire [email protected] et secondaire ryan. [email protected] , cependant GitHub n'a pas la possibilité d'afficher publiquement les adresses e-mail secondaires. Je n'ai qu'un seul compte LF, qui a [email protected] comme e-mail et est déjà lié à mon compte GitHub, et le CLA est soumis, mais il semble n'y avoir aucun moyen de le configurer pour que mon adresse canonique.com signe le CLA.

Salut. J'essaie de m'inscrire à la CNCF CLA pour pouvoir soumettre du code, et je n'y parviens pas. C'est le PR où le contrôle correspondant échoue :

https://github.com/kubernetes-incubator/external-dns/pull/376

Les commits ont été effectués à l'aide de mon adresse e-mail professionnelle. Je me suis inscrit à LinuxFoundation en utilisant mon compte Github privé et l'adresse e-mail privée associée (différente de l'adresse e-mail de l'entreprise), puis j'ai changé mon adresse e-mail pour qu'elle soit identique à celle de l'entreprise. À partir de là, j'ai signé la société de mon employeur en tant qu'organisation à la fondation Linux, avec moi (et quelques autres employés) en tant que gestionnaire. La vérification de l'autorité de certification échoue toujours.

En désespoir de cause, j'ai ensuite changé l'adresse e-mail en une adresse privée et créé un deuxième compte LF entièrement nouveau avec un nom d'utilisateur différent et mon adresse e-mail d'entreprise comme adresse e-mail, et j'ai réussi à inviter et à rejoindre cet utilisateur dans le groupe. La vérification de l'autorité de certification échoue toujours.

Comment savoir ce qui manque ? S'il vous plaît aider.

MISE À JOUR : Ça marche maintenant. Merci @BenTheElder et les personnes de soutien de la fondation LF.

Y a-t-il une raison particulière pour laquelle ce problème est toujours ouvert ? Ne sommes-nous pas passés au système LF CLA ? Doit-il être renommé pour refléter un changement de portée ?

@spiffxp Il serait approprié de renommer quelque chose comme "Problèmes agrégés avec LF CLA".

Pour votre information, le LF déploiera bientôt une réécriture de notre CLAbot qui, espérons-le, traitera la plupart des flux de travail qui ont causé des problèmes à ce jour. Lorsque cela se produit, nous pouvons créer un nouveau problème et fermer celui-ci.

Renommé

J'ai accidentellement saisi la mauvaise adresse e-mail lors de l'inscription à un CLA individuel. Par conséquent, le "Contrat de Licence Contributeur Individuel CNCF - Demande de signature" a été envoyé à la mauvaise adresse.
J'ai mis à jour l'adresse e-mail dans les paramètres du compte entre-temps.

Est-il possible de recevoir une nouvelle "Demande de signature" à l'adresse corrigée ?

@axdotl Veuillez envoyer un e-mail à [email protected] et ils prendront soin de vous.

@dankohn Merci !

J'obtiens cette erreur lorsque j'essaie de m'inscrire en tant que contributeur individuel avec mon github :

Sorry, there is a temporary problem signing up contributors for this project. Please try again later.

@enis C'est un message d'erreur inutile. Pourriez-vous envoyer un e-mail à [email protected].

@emsearcy @alanapost pourriez-vous s'il vous plaît voir si quelque chose ne va pas.

(Aussi répondu via le service d'assistance)

La cause de ce problème était que GitHub ne renvoyait supposément que des adresses e-mail validées via Oauth, mais pour ce compte, ils ont fourni une adresse e-mail malformée/obscurcie (sans aucun signe @) qui a été utilisée pour ce compte. Le composant de signature électronique a rencontré un cas limite car il n'a pas été testé avec des chaînes d'e-mail non conformes.

Nous appliquerons un correctif dans le logiciel, ce qui obligera l'utilisateur à corriger toute adresse e-mail malformée puis à la valider via notre site.

Merci Éric,

J'ai pu utiliser mon compte "enis" pour le CLA.

Merci pour l'aide. On peut fermer ça.
Énis

Le mar. 21 novembre 2017 à 16h21, Eric Searcy [email protected]
a écrit:

(Aussi répondu via le service d'assistance)

La cause de ce problème était que GitHub ne renvoyait censément que validé
adresses e-mail via Oauth, mais pour ce compte, ils ont fourni un
adresse e-mail malformée/masquée (sans aucun signe @) qui a été utilisée pour
ce compte. Le composant de signature électronique a rencontré un cas limite car il n'était pas
testé avec des chaînes de messagerie non conformes.

Nous appliquerons un correctif dans le logiciel, ce qui obligera l'utilisateur à
corrigez toute adresse e-mail malformée puis validez-la via notre site.


Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/27796#issuecomment-346203677 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAO1MF8kE4C7uanISq6r_-vl2LdlbZdVks5s42kPgaJpZM4I7IQL
.

Je n'arrive pas à obtenir un CNCF-CLA signé avec l'adresse e-mail de l'entreprise.

J'ai d'abord essayé de signer un CNCF-CLA en me connectant avec mon compte github.com, j'ai vu que le CLA avait mon compte de messagerie personnel répertorié et j'ai réalisé que mon corp. l'adresse e-mail n'avait pas encore été ajoutée à mon compte gh.

J'ai annulé le formulaire, je suis allé à GH et j'ai ajouté mon adresse e-mail professionnelle, puis j'ai essayé de signer à nouveau le CLA mais je ne vois qu'un message indiquant que le CLA a été envoyé à mon adresse e-mail. Aucun formulaire CLA n'a été reçu - via mon adresse e-mail personnelle ou professionnelle.

@greglanthier Pourriez-vous envoyer un e-mail à [email protected] et ils vous aideront à vous débrouiller.

Bonjour, je me suis inscrit en utilisant le compte github mais je n'avais pas réalisé qu'il utilisait une ancienne adresse e-mail que je ne veux plus utiliser. J'ai toujours accès à l'ancien e-mail pour le moment. J'essaie de changer l'adresse e-mail sur mon profil Linux Foundation mais j'obtiens cette erreur au-dessus d'un message indiquant que je vais recevoir un e-mail.

    An attempt to send an e-mail message failed.
    Unable to send e-mail. Contact the site administrator if the problem persists.
    An attempt to send an e-mail message failed.
    Unable to send e-mail. Contact the site administrator if the problem persists.

A confirmation email has been sent to your new email address. You must follow the link provided in that email within 24 hours in order to confirm the change to your account email address.

Je ne reçois pas d'e-mails et je pense que c'est à cause du message d'erreur ci-dessus. Toute aide serait appréciée.
Merci.

Veuillez contacter [email protected] et ils régleront le problème pour vous.

--
Dan Kohn [email protected]
Directeur Exécutif, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com

Le 8 janvier 2018 à 10h32, Christian Roy [email protected] a écrit :

Bonjour, je me suis inscrit en utilisant le compte github mais je n'avais pas réalisé qu'il utilisait une ancienne adresse e-mail que je ne veux plus utiliser. J'ai toujours accès à l'ancien e-mail pour le moment. J'essaie de changer l'adresse e-mail sur mon profil Linux Foundation mais j'obtiens cette erreur au-dessus d'un message indiquant que je vais recevoir un e-mail.

An attempt to send an e-mail message failed.
Unable to send e-mail. Contact the site administrator if the problem persists.
An attempt to send an e-mail message failed.
Unable to send e-mail. Contact the site administrator if the problem persists.

Un e-mail de confirmation a été envoyé à votre nouvelle adresse e-mail. Vous devez suivre le lien fourni dans cet e-mail dans les 24 heures afin de confirmer le changement d'adresse e-mail de votre compte.
Je ne reçois pas d'e-mails et je pense que c'est à cause du message d'erreur ci-dessus. Toute aide serait appréciée.
Merci.


Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

J'ai signé la CLA en tant que contributeur individuel dans le passé.
Maintenant, je travaille pour une entreprise où je vais apporter des contributions pendant le temps de travail et, évidemment, la propriété intellectuelle appartient à l'entreprise lorsque je le fais. Mais tout ce que je fais en dehors du travail n'appartient pas à l'entreprise.

Mes questions:

  • Comment changer mon compte de "Particulier" à "Employé" ? J'ai déjà changé l'adresse e-mail, mais je ne trouve pas le bouton pour le changer.
  • Comment puis-je refléter le fait que l'IP des choses que je crée dépend du contexte (quand je crée des choses et ce que c'est) ? Ce n'est pas rare dans le droit du travail européen. Parce qu'il est illégal pour les entreprises de revendiquer tout ce que les gens créent alors qu'ils sont employés dans de nombreuses juridictions.
  • Donc, techniquement, je peux être à la fois (le contributeur de Schrödinger) un contributeur individuel et un collaborateur en fonction de certaines circonstances. Comment puis-je garder les deux choses signées ?

J'ai signé le CLA en tant qu'individu et intégré à GitHub. J'ai un PR en attente qui se plaint que je ne l'ai pas fait. J'ai vérifié que l'e-mail sur le commit correspond à mon GitHub qui a été vérifié.

Peux tu vérifier s'il te plaît?

Voici un lien vers le PR:
https://github.com/kubernetes/kubernetes/pull/60962

@technicianted Veuillez contacter [email protected] et ils régleront le problème pour vous.

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme nouveau avec /remove-lifecycle stale .
Les problèmes obsolètes pourrissent après 30 jours d'inactivité supplémentaires et finissent par se fermer.

Si vous pouvez fermer ce problème en toute sécurité maintenant, faites-le avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/ cycle de vie obsolète

Les problèmes obsolètes pourrissent après 30 jours d'inactivité.
Marquez le problème comme nouveau avec /remove-lifecycle rotten .
Les problèmes pourris se ferment après 30 jours d'inactivité supplémentaires.

Si vous pouvez fermer ce problème en toute sécurité maintenant, faites-le avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/ cycle de vie pourri
/supprimer le cycle de vie obsolète

Les problèmes pourris se ferment après 30 jours d'inactivité.
Rouvrez le problème avec /reopen .
Marquez le problème comme nouveau avec /remove-lifecycle rotten .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/Fermer

/rouvrir

Reste un obstacle majeur aux nouveaux contributeurs

/supprimer le cycle de vie pourri

Pour votre information, la semaine dernière, lors de l'atelier des nouveaux contributeurs de KubeCon / CloudNativeCon China, j'ai observé de nombreux (la plupart ?) Des participants aux prises avec l'UI/UX dans :

https://camo.githubusercontent.com/cdcaa8a1b2679acb1c8452091a05e27c8e68bc54/687474703a2f2f692e696d6775722e636f6d2f74456b3278336a2e706e67

Deux choses précisément :

  • Facebook, Google, GitHub, OpenStack sont à des degrés divers spécifiques à un emplacement ou à un écosystème et également graphiques, donc probablement pas traduits dans le navigateur.
  • la moitié alternative "Ou - LOG IN" de l'élément de connexion ne se distingue pas clairement comme un élément cliquable par opposition à un simple texte sur le thème bleu de la Linux Foundation dans une boîte bleue.

Étant donné que GitHub est généralement requis pour la participation, il peut être visuellement plus facile de n'avoir que deux cases :

  1. Connectez-vous avec GitHub
  2. Connectez-vous avec l'ID Linux Foundation

et supprimez les autres options de l'écran pour simplifier visuellement. Si seul l'identifiant Linux Foundation sélectionné par la personne a _alors_ un écran qui demande son identifiant Linux Foundation existant ou permet d'en créer un.

Je soupçonne que la plupart des gens choisiront simplement GitHub et c'est le flux pour lequel la boîte de dialogue doit être optimisée.

J'ai essayé de signer le CLA pour poursuivre mon PR https://github.com/kubernetes/kubernetes/pull/72275 mais je n'ai pas reçu l'accord par e-mail malgré de nombreux essais. J'ai également contacté [email protected] il y a 2 jours mais je n'ai pas encore reçu de réponse - il semblerait que leurs réponses seront minimes/retardées car c'est la période des vacances. J'espérais un moyen de me débloquer sur ce PR bientôt.

Excuses @srmocher mais le service d'assistance de la Linux Foundation ne pourra pas résoudre ce problème avant le 2 janvier.

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme nouveau avec /remove-lifecycle stale .
Les problèmes obsolètes pourrissent après 30 jours d'inactivité supplémentaires et finissent par se fermer.

Si vous pouvez fermer ce problème en toute sécurité maintenant, faites-le avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/ cycle de vie obsolète

/supprimer le cycle de vie obsolète
/cycle de vie gelé

Cette page vous a été utile?
0 / 5 - 0 notes