Scinder une PR par groupes CODEOWNERS

Scinder une grande pull request en plusieurs PRs plus petites, où chaque PR touche le moins possible de groupes de reviewers CODEOWNERS. L'objectif est de réduire la charge de review : une PR qui touche uniquement megatron/core/ nécessite seulement les reviewers du core, tandis qu'une PR qui touche aussi examples/, tools/, et megatron/training/ mobilise de nombreux groupes supplémentaires.

Contraintes prioritaires pour les questions de scission

Pour les questions de planification de scission, présentez ces contraintes avant le workflow complet :

Minimisez les groupes de reviewers CODEOWNERS par PR, mais chaque PR résultante doit rester indépendamment fusionnable et reviewable.
Les tests voyagent avec le code de production qu'ils valident ; ne scindez pas les tests dans une PR séparée simplement pour réduire les groupes de reviewers.
Si la PR B dépend de symboles renommés dans la PR A, signalez la dépendance et insérez des alias rétro-compatibles, des réexportations ou des shims dans la PR A si nécessaire.
Attendez l'approbation de l'utilisateur avant l'exécution.
L'exécution crée des draft PRs à partir de la bonne base, applique des diffs limités au scope des fichiers avec git diff upstream/main..<source-branch> -- <paths> | git apply, pousse vers le fork de l'utilisateur, et ne pousse jamais directement vers upstream.

Workflow

1. Analyser la PR

Récupérez les détails de la PR : gh pr view <number> --repo NVIDIA/Megatron-LM --json title,body,headRefName,author et gh pr diff <number> --repo NVIDIA/Megatron-LM --stat. Déterminez aussi l'utilisateur GitHub courant avec gh api user --jq .login.
Parsez .github/CODEOWNERS pour construire un mapping des patterns de chemins de fichiers vers les groupes de propriétaires.
Pour chaque fichier modifié dans la PR, déterminez quels groupes CODEOWNERS seraient tenus de le reviewer.
Constituez un tableau récapitulatif groupé par groupe CODEOWNERS, montrant quels fichiers mobilisent quels groupes.
Comptabilisez le nombre total de groupes de reviewers distincts que la PR requiert actuellement.

2. Proposer une scission qui minimise les groupes de reviewers par PR

L'objectif d'optimisation principal : minimiser le nombre de groupes de reviewers CODEOWNERS requis pour chaque PR résultante.

Stratégie :

Regroupez les fichiers par leurs groupes CODEOWNERS. Les fichiers possédés par le même ensemble de groupes appartiennent naturellement ensemble.
Identifiez le plus grand cluster — celui-ci devient la première PR (et habituellement la plus volumineuse).
Les fichiers restants forment une ou plusieurs PRs supplémentaires, chacune requérant idéalement un ou deux groupes de reviewers seulement.
Si une scission crée une dépendance (par ex., la PR B utilise des symboles renommés dans la PR A), la PR dépendante doit être fusionnée après la première. Notez cela explicitement.
Chaque PR doit être indépendamment fusionnable vers main — pas d'imports cassés, pas de symboles manquants. Les alias rétro-compatibles et les stubs de réexportation dans la première PR peuvent le rendre possible.

Présentez la scission proposée sous forme de tableau :

Nom/description de la PR
Fichiers inclus
Groupes CODEOWNERS requis
Dépendances sur d'autres PRs (le cas échéant)

Attendez l'approbation de l'utilisateur avant de procéder.

3. Exécuter la scission (après approbation de l'utilisateur)

Pour chaque nouvelle PR :

Créez une nouvelle branche à partir de la bonne base (main, ou la branche d'une PR dépendante).
Extrayez les modifications pertinentes : git diff upstream/main..<source-branch> -- <file paths> | git apply.
Stagez, committez avec un message clair, et poussez vers le fork de l'utilisateur.
Créez la PR comme un draft (selon les directives de contribution du repo).
Si la PR originale doit être réduite en scope, confirmez avec l'utilisateur avant une force-push.
Reportez toutes les URLs des PRs quand c'est fait.

Directives importantes

Créez toujours les PRs comme des drafts et poussez vers le fork de l'utilisateur, jamais directement vers upstream.
Les changements rétro-compatibles (aliases, réexportations, shims de dépréciation) doivent aller dans la première PR pour que les PRs ultérieures puissent en dépendre.
Les fichiers de tests doivent accompagner le code de production qu'ils testent, pas dans une PR séparée.
Préférez un seul commit propre par PR scindée plutôt que de rejouer l'historique de commits original.
Si un fichier est difficile à catégoriser (par ex., il touche deux groupes), demandez à l'utilisateur dans laquelle des PRs il devrait aller.
Si l'utilisateur GitHub courant n'est pas l'auteur de la PR originale, la description de chaque nouvelle PR doit explicitement créditer l'auteur original (par ex., « Changements originaux par @<author> dans #<number> »).

mcore-split-pr