Règles des privilèges Gerrit
 | Cette page documente une règle du développement Wikimedia officielle. Il n'existe actuellement aucun mécanisme pour faire des modifications car le processus RFC de TechCom n'est plus opérationnel. |
| Règles du développement |
|---|
| Voir aussi |
| Guide du développement |
Droits et responsabilités
La plupart des dépôts Gerrit Wikimedia sont configurés de sorte que lorsqu'un utilisateur attribue un +2 à la relecture de code, Jenkins fusionne automatiquement les modifications après avoir exécuté les tests.
Donc le droit d'attribuer un +2 à la relecture du code est restreint et n'est possible que pour les utilisateurs de certains groupes Gerrit.
Pour chaque répertoire il existe typiquement un groupe Gerrit nommé, ayant les droits correspondants.
Certains groupes Gerrit permettent également d'étendre les privilèges sur plusieurs répertoires.
Le plus remarquable est certainement que le groupe mediawiki donne des privilèges sur le noyau MediaWiki ainsi que toutes les extensions et les habillages, et sur quelques autres répertoires liés à MediaWiki.
Les groupes Gerrit peuvent dériver leurs membres à partir des groupes LDAP.
La plupart des employés de la WMF sont dans le groupe wmf en LDAP, ce qui leur confère directement les droits du groupe mediawiki.
Les administrateurs Gerrit peuvent ajouter ou supprimer des membres aux groupes Gerrit.
Intégrer les modifications dans le noyau MediaWiki ou dans une extension déployée par Wikimedia est un grand défi. Les modifications seront automatiquement déployées dans le Bêta Cluster, un environnement virtualisé d'attente, aussitôt qu'elles seront fusionnées dans Gerrit. Il sera aussi pris automatiquement en compte dans la fenêtre du prochain déploiement du noyau MediaWiki (voir Déploiements) sauf s'il est annulé avant que la branche de version ne soit supprimée.
L'intégration de votre code peut casser Wikipedia ou d'autres sites. Cela peut créer une faille de sécurité et permettant des attaques visant à détruire ou à corrompre les données, ou à accéder à des informations privées. Et dans le cas le plus fréquent, il peut augmenter le Dette technique si le code ne contient pas de tests, ou qu'il est trop simplement implémenté ou trop peu socialisé. Avant d'utiliser le +2 vous devriez lire soigneusement ce document ainsi que toutes les polices correspondantes.
+2 a une signification importante de confiance, et cette confiance est garantie par le bon jugement et une action soignée.
Dans les revues de code, les discussion d'architecture et les commentaires de bogues, ceux qui peuvent attribuer un +2 ont une responsabilité particulière à prendre en compte d'autres points de vue.
Fusionner sans faire de revue
Fusionner le code sans relecture est mauvais pour la qualité du code ainsi que sur le principe. L'attribution d'un +2 permet de séparer le développement de la relecture de code. Le but de l'intégration d'une modification dans Gerrit est de dire au monde que « oui, j'ai vérifié que ces modifications sont conformes aux conventions de MediaWiki, aux bons principes du codage et qu'elles sont saines » . (voir « Les revues de code : faites-les simplement » par Jeff Atwood.) Les commentaires en ligne peuvent être utilisés pour signaler les problèmes posés par le code et devant être corrigés avant que le code ne soit fusionné.
Intégrer son propre code sans l'approbation d'un relecteur peut être prétexte à la révocation de vos privilèges.
Ce n'est pas nécessairement la même chose que de s'attribuer un +2 à une correction personnelle. Par exemple :
- Si une modification reçoit un +2 d'un relecteur, et que la compilation Jenkins échoue, son propriétaire peut redonner un +2 pour relancer la tâche de compilation.
- Les annulations peuvent généralement être auto-fusionnées tant que le commit qui fait l'objet de l'annulation est récent. Vous revenez en arrière sur une version qui suppose avoir été relue en son temps.
- Dans les branches de déploiement et dans le dépôt Puppet, les modifications sont fusionnées par la personne qui fait le déploiement et c'est souvent l'auteur. Dans ces cas, la revue de code est signalée typiquement par l'attribution de +1 aux modifications.
- Un commit dans Gerrit peut avoir deux auteurs : un propriétaire et un relecteur qui téléverse un amendement. Typiquement, le propriétaire et le relecteur se relisent le travail mutuellement. Tant que toutes les modifications ont été relues et sont approuvées, le commit peut être fusionné.
Seuls quelques modifications sont évidentes pour être intégrées directement. L'auto-fusion est autorisée dans certains cas comme les modifications triviales de la documentation ou les projets qui n'ont qu'une seule personne pour la maintenance.
Pour les extensions (et les autres projets) non déployés dans la grappe Wikimedia, la politique des revues de code dépend du mainteneur ou de l'auteur de l'extension. Certaines extensions non-Wikimedia suivent les règles de Wikimedia concernant l'interdiction des auto-fusions, mais il n'y a pas d'obligation à cela. Si vous seul écrivez l'extension et que vous n'avez personne pour relire vos modifications, ou bien si l'extension est abandonnée, vous pouvez auto-fusionner vos modifications.
Revue au sein d'une même équipe et paternité partagée
Si vous travaillez au sein d'une équipe, la relecture du code par les membres de votre équipe n'est pas seulement permise mais surtout fortement encouragée. Le fait d'avoir des pairs qui relisent votre code régulièrement leur permet de suivre l'évolution du développement et assure que vos relecteurs sont familiers avec ce que vous faites.
Si les relectures de code se font à l'intérieur de votre équipe, faites particulièrement attention aux points d'aveuglément, aux biais cognitifs, et au besoin de forces supplémentaires pour les modifications importantes et externes au groupe dans lequel vous travaillez. La plupart des projets à source ouvert, y compris MediaWiki, regorgent d'efforts ayant été abandonnés pour créer de nouveaux niveaux d'abstraction sympathiques, des systèmes d'habillages, des environnements de test, etc. Tenez compte de l'impact qu'auront vos mdifications sur l'écosystème dans sa globalité, et prenez part aux conversations via les demandes de commentaires (RFC), wikitech-l, les canaux IRC et autres possibilités. Le partage de la paternité du code (à un degré plus ou moins grand) permet de s'assurer que ce que vous faites aura une valeur garantie dans le temps.
A lire obligatoirement par les relecteurs de code
- Guide de la revue de code
- Sécurité pour les développeurs
- Conventions de codage - et les sous-pages
- Tests unitaires - et les pages relatives
- Internationalisation
- Database optimization - souvenez-vous de cela lorsque vous modifiez le schéma (à implémenter en suivant ce processus)
- Comment déboguer
Demander les droits Gerrit
Pour demander votre rattachement au groupe mediawiki, créez une nouvelle tâche dans le projet MediaWiki-Gerrit-Group-Requests de Phabricator.
Puis envoyez un courriel à la liste de diffusion wikitech-l.
Pour demander à être rattaché à un autre groupe, créez une nouvelle tâche dans le projet Gerrit-Privilege-Requests de Phabricator.
Dans tous les cas, la tâche Phabricator doit spécifier :
- le nom d'utilisateur Gerrit
- le ou les répertoires pour lesquels vous demander l'accès
- être argumenté, en comprenant des liens vers les corrections que vous avez écrites et les revues
Les développeurs ayant à apprécier une demande de droits doivent prendre en considération le fait que le demandeur a contribué en apportant des corrections de bonne qualité ou pas, s'il a également participé en attribuant des +1, et s'il a fait preuve de compétence. Les commentaires négatifs doivent être écrits avec tact, et ne pas être trop acerbes.
Si un accord est trouvé parmi les développeurs de confiance sur la tâche Phabricator, n'importe quel administrateur Gerrit peut répondre positivement à la requête. La tâche doit rester ouverte durant au moins une semaine afin de permettre aux développeurs intéressés, d'y laisser leur commentaire. Du temps supplémentaire peut être attribué si la requête a été ouverte pendant les périodes de voyage ou de vacance.
Si aucun consensus ne peut être trouvé sur une requête dans Phabricator, il est possible de faire appel à TechCom pour statuer.
Auparavent, les droits d'accès sur les projets respectifs dans Gerrit étaient attribués à certains mainteneurs d'extensions afin qu'ils puissent ajouter de nouveaux membres au groupe sans passer par une demande dans Phabricator. Ce modèle ne doit pas être utilisé pour les nouvelles extensions. Les administrateurs Gerrit ne doivent pas attribuer de droits sur le dépôt aux développeurs communs. Avant qu'une extension ne soit déployée sur la grappe Wikimedia pour la première fois, les droits doivent être audités et les anciens droits d'accès doivent être rétrogradés à l'accès +2.
Processus accéléré pour les organisations de confiance
Les administrateurs Gerrit peuvent agir immédiatement sur demande des organisations de confiance suivantes pour attribuer ou supprimer les droits d'appartenance aux groupes dont ils ont la charge, particulièrement :
| Organisation | Groupes organisés |
|---|---|
| Wikimedia Deutschland | wmde, wmde-mediawiki
|
| ShoutWiki | ShoutWiki, Brickimedia
|
| Hallo Welt! | bluespice
|
| WikiTeq | WikiTeq
|
Il n'est pas nécessaire de créer une tâche dans Phabricator ni d'expliquer le consensus.
Cette facilité est destinée à permettre à ces organisations d'intégrer rapidement des collaborateurs, supposés dignes de confiance de par le processus de recrutement. Il permet également aux organisations de confiance d'accorder l'accès à des bénévoles bien connus et dignes de confiance de ces organisations.
Les employés WMF peuvent être ajoutés au groupe wmf dans LDAP lorsqu'ils sont embauchés.
Les employés de Wikimedia Deutschland peuvent être ajoutés au groupe wmde en LDAP lorsqu'ils sont engagés.
Le TechCom, ou le CTO en accord avec TechCom, peuvent demander à un administrateur Gerrit d'ajouter toute personne à un groupe Gerrit.
Révocation
La révocation des droits Gerrit est permise dans les circonstances suivantes :
- En cas d'urgence comme pour un compte usurpé, les administrateurs Gerrit peuvent bloquer l'accès immédiatement selon leur appréciation. L'annulation de la révocation d'urgence peut être faite à l'appréciation de l'administrateur s'il estime que l'urgence est passée. Le TechCom ou le CTO en accord avec TechCom, peuvent analyser une révocation d'urgence et demander son annulation.
- La révocation des privilèges d'un employé de la WMF peut être demandée par le responsable de cet employé, en consultation avec le WMF Talent and Culture, comme indiqué dans le Manuel du personnel.
- La suppression des droits d'une personne quelconque peut être demandée par le TechCom, ou par le CTO en consultation avec TechCom.
Les motifs de révocation peuvent inclure :
- Fusion de code erronné
- Fusionner son propre code sans revue
- Ne pas faire connaître les modifications à fort impact à la communauté de développement
- Ne pas suivre les règles ci-dessus
- Comportement non approprié, en particulier violation du Code de conduite
- Arrêt de la collaboration ou du contrat
La politique de la WMF est de révoquer tous les privilèges lors du départ des membres du personnel, même si ces privilèges ont été accordés avant le début de l'emploi en vertu d'un travail bénévole. L'application cohérente de cette politique contribue à protéger la vie privée des membres du personnel révoqués : aucune faute n'est impliquée. Si les membres du personnel révoqués souhaitent continuer à contribuer à titre bénévole, ils peuvent présenter une nouvelle demande d'accès par le processus habituel.
Demander la révocation
La révocation d'urgence doit être demandée directement en contactant un administrateur Gerrit, par exemple en utilisant IRC. La révocation pour des motifs de compétence ou de comportement doit généralement être traitée en privé, à la suite d'une montée en tension. Pour les détails, voir le tableau suivant :
| Scénario | Action |
|---|---|
|
|
|
|
|
|
Amendements à cette police
Les amendements à cette police doivent être approuvés par le CTO, en accord avec le TechCom.
Définitions
- CTO
- Officier technique en chef de la Fondation WikiMedia.
- TechCom
- Comité technique Wikimedia. Pour que le TechCom puisse décider ou entreprendre une action, il faut une réunion du comité, soit à distance par audio/video conférence soit en personne, avec la participation d'un quorum d'au moins la moitié des membres du TechCom, afin d'établir une résolution à la majorité simple ou par consentement unanime.