Raccourci : Gerrit/+2

Règles des privilèges Gerrit

From mediawiki.org
Jump to navigation Jump to search
This page is a translated version of the page Gerrit/Privilege policy and the translation is 72% complete.
Other languages:
English • ‎Türkçe • ‎français • ‎বাংলা • ‎日本語

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, ainsi que 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 les membres des groupes Gerrit.

Intégrer les modifications dans le noyau de MediaWiki ou dans une extension déployée par Wikimedia est un grand défi. Les modifications seront automatiquement déployées dans Beta 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 technical debt 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 pour 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 soit fusionné.

Intégrer son propre code sans 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 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 à sources ouverts, 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

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 :

  • Nom d'utilisateur Gerrit
  • le ou les répertoires pour lesquels vous demander l'accès
  • reasoning, including links to patches written and reviewed

Developers commenting on a privilege request should consider whether the applicant has contributed high quality patches, has exercised +1 rights well, and has demonstrated competence. Negative comments should be written with tact, they should not be overly strident.

If there is a consensus of trusted developers on the Phabricator task, any of the Gerrit administrators can resolve the request. The task must remain open for at least a week, to allow interested developers to comment. Additional time should be allowed if the request is open during travel or holiday periods.

If there is no consensus on a request in Phabricator, it may be referred to TechCom for adjudication.

Previously, some extension maintainers were given ownership rights on the relevant project in Gerrit, so that they could add new group members without making a request in Phabricator. This model should not be used for new extensions. Gerrit administrators should not grant repository ownership to ordinary developers. Before an extension is deployed to the Wikimedia cluster for the first time, the rights should be audited, and legacy ownership privileges should be downgraded to +2 access.

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 sur les groupes associés, particulièrement :

Organisation Groupes organisés
Wikimedia Deutschland wmde, wmde-mediawiki
ShoutWiki ShoutWiki, Brickimedia
Hallo Welt! bluespice
WikiTeq WikiTeq

It is not necessary to file a Phabricator task or demonstrate consensus.

This facility is intended to allow these organisations to rapidly on-board staff members, who are assumed to be trusted by virtue of the hiring process. It also allows trusted organisations to grant access to volunteers who are well known and trusted by those organisations.

WMF employees may be added to the wmf group in LDAP when they are hired. Wikimedia Deutschland employees may be added to the wmde group in LDAP when they are hired.

TechCom, or the CTO in consultation with TechCom, may direct a Gerrit administrator to add any person to a Gerrit group.

Révocation

La révocation des droits Gerrit est permise dans les circonstances suivantes :

  • In an emergency, such as a compromised account, Gerrit administrators may revoke access immediately, at their discretion. Reversal of emergency revocation may be done at the administrator's discretion if the emergency is judged to have passed. TechCom, or the CTO in consultation with TechCom, may review an emergency revocation and direct its reversal.
  • Revocation of privileges of a WMF employee may be directed by that employee's manager, in consultation with WMF Talent and Culture, as discussed in the Staff Handbook.
  • Revocation of privileges from any person may be directed by TechCom, or by the CTO in consultation with TechCom.

Les motifs de révocation peuvent inclure :

  • Fusion de code erronné
  • Fusionner son propre code sans revue
  • Failing to socialize high impact changes within the development community
  • Not following the guidelines above
  • Inappropriate behaviour, in particular, violating the Code of Conduct
  • Arrêt de la collaboration ou du contrat

It is WMF policy to revoke all privileges when staff members depart, even if those privileges were granted prior to the beginning of employment by virtue of volunteer work.

Consistent application of this policy helps to protect the privacy of departing staff members: no fault is implied. If departed staff members wish to continue to contribute in a volunteer capacity, they may reapply for access by the usual process.

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
  • Un développeur téléverse et réalise des auto-fusions de code vandalisant.
  • Contactez d'urgence un administrateur Gerrit qui révoquera les droits.
  • A developer shows a pattern of merging flawed changes, without proper review.
  • Un développeur s'obstine à fusionner son propre code en violant les normes communautaires.
  • Si le développeur est un employé WMF ou d'une organisation de confiance, rapportez le problème à son responsable.
  • If the manager's response was unsatisfactory, or if the developer is not an employee, report the problem to TechCom.
  • If TechCom's response is unsatisfactory, you may report the problem to the CTO.
  • A developer uses their +2 access to bully or intimidate developers seeking review.
  • Other behaviour issues or Code of Conduct violations.
  • If the developer is an employee of WMF or a trusted organisation, and you feel comfortable doing so, report the problem to their manager.
  • Otherwise, report the problem either to TechCom or to the Code of Conduct committee.
  • Si la réponse du comité n'est pas satisfaisante, vous pouvez remonter le problème au CTO.

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.