Vue imprimable multi-pages de cette section. .
Tri
1 - Guidelines de tri des problèmes
Objectif
Accélérer la gestion des problèmes.
Les problèmes liés à etcd sont répertoriés sur https://github.com/etcd-io/etcd/issues
et sont identifiés par des étiquettes. Par exemple, un problème identifié
comme un bogue sera éventuellement étiqueté area/bug . Les nouveaux problèmes
apparaissent initialement sans étiquette, mais les responsables etcd et les contributeurs actifs
ajoutent des étiquettes en fonction de leurs constatations. La liste détaillée des étiquettes est disponible sur
https://github.com/kubernetes/kubernetes/labels
Voici quelques recherches prédéfinies sur les problèmes, pour plus de commodité :
Portée
Ces directives servent de document principal pour trier les problèmes reçus dans etcd. Tous sont invités à aider à la gestion des problèmes et des demandes de tirage, mais le travail et les responsabilités décrits dans ce document sont destinés aux mainteneurs et contributeurs actifs de etcd.
Vérifier qu’un problème est un bogue
Vérifiez si le problème est bien un bogue. Si ce n’est pas le cas, ajoutez un commentaire avec vos constatations et fermez l’issue mineure. Pour une issue non mineure, attendez de recevoir une réponse du rapporteur d’incident et vérifiez s’il y a une objection. Si le rapporteur d’incident ne répond pas dans les 30 jours, fermez l’issue. Si le problème ne peut pas être reproduit ou s’il nécessite des informations supplémentaires, laissez un commentaire pour le rapporteur d’incident.
Problèmes inactifs
Les problèmes qui manquent d’informations fournies par le rapporteur doivent être fermés si ce dernier ne fournit pas d’informations dans les 60 jours.
Problèmes en double
Si un problème est en double, ajoutez un commentaire indiquant cette situation, accompagné d’une référence vers le problème original, puis clôturez-le.
Problèmes qui n’appartiennent pas à etcd
Parfois, des problèmes sont signalés qui appartiennent en réalité à d’autres projets utilisant etcd. Par exemple, des problèmes liés à grpc ou golang. Ces problèmes doivent être traités en demandant au signalement de créer une issue dans le projet approprié. Fermer l’issue, sauf si un mainteneur et le signaleur estiment nécessaire de la laisser ouverte pour des raisons de suivi.
Vérifier que les étiquettes importantes sont présentes
Assurez-vous que l’issue dispose des étiquettes correspondant aux domaines auxquels elle appartient, que les assignataires appropriés sont ajoutés et que l’échéance est définie. Si l’une de ces étiquettes est manquante, ajoutez-la. Si les étiquettes ne peuvent pas être attribuées en raison de privilèges limités ou si l’étiquette correcte ne peut pas être déterminée, cela ne pose pas de problème ; contactez les responsables si nécessaire.
Poke le propriétaire de l’issue si nécessaire
Si une issue dont le propriétaire est un développeur n’a pas de demande de fusion (PR) créée en 30 jours, contactez le propriétaire de l’issue et demandez une PR ou la libération de la propriété si nécessaire.
2 - Gestion des demandes de tirage
Objectif
Accélérer la gestion des PR.
Les demandes de fusion etcd sont listées sur https://github.com/etcd-io/etcd/pulls
Une demande de fusion peut avoir divers étiquettes, un délai d’achèvement, un validateur, etc. La liste détaillée des étiquettes est disponible sur
https://github.com/kubernetes/kubernetes/labels
Voici quelques exemples de recherches sur PR pour plus de commodité :
Portée
Ces directives servent de document principal pour la gestion des demandes de tirage (PR) dans etcd. Tous sont invités à aider à la gestion des PR, mais le travail et les responsabilités décrits dans ce document s’adressent principalement aux mainteneurs et contributeurs actifs de etcd.
Gérer les demandes de tirage inactives
Poke le propriétaire de la PR si les commentaires de relecture ne sont pas traités en 15 jours. Si le propriétaire de la PR ne répond pas en 90 jours, mettez à jour la PR avec un nouveau commit si possible. Sinon, une PR inactif doit être fermée après 180 jours.
Interroger le réviseur si nécessaire
Les relecteurs sont réactifs de manière ponctuelle, mais étant donné que chacun est occupé, accordez-leur un délai après la demande de relecture si la réponse rapide n’est pas fournie. Si aucune réponse n’est donnée dans les 10 jours, n’hésitez pas à les contacter en ajoutant un commentaire dans la demande de fusion, en envoyant un courriel ou un message sur Slack.
Vérifier que les étiquettes importantes sont présentes
Assurez-vous que les revueurs appropriés sont ajoutés à la demande de fusion (PR). Vérifiez également qu’une étiquette de livrable (milestone) est définie. Si l’une de ces étiquettes ou toute autre étiquette importante est manquante, ajoutez-la. Si aucune étiquette correcte ne peut être déterminée, laissez un commentaire pour inviter les responsables à intervenir selon le besoin.