Diviser une PR par groupes CODEOWNERS

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

Workflow

1. Analyser la PR

Récupérer 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éterminer aussi l'utilisateur GitHub actuel avec gh api user --jq .login.
Parser .github/CODEOWNERS pour construire une correspondance entre les motifs de chemins de fichiers et les groupes propriétaires.
Pour chaque fichier modifié dans la PR, déterminer quels groupes CODEOWNERS seraient requis pour le relire.
Construire un tableau récapitulatif groupé par groupe CODEOWNERS, montrant quels fichiers mobilisent quels groupes.
Compter le nombre total de groupes de relecteurs distincts que la PR requiert actuellement.

2. Proposer un découpage qui minimise les groupes de relecteurs par PR

Objectif d'optimisation principal : minimiser le nombre de groupes de relecteurs CODEOWNERS requis pour chaque PR résultante.

Stratégie :

Regrouper les fichiers par leurs groupes CODEOWNERS. Les fichiers possédés par le même ensemble de groupes appartiennent naturellement ensemble.
Identifier le plus grand cluster — celui-ci devient la première PR (et généralement la plus grande).
Les fichiers restants forment une ou plusieurs PR supplémentaires, chacune requérant idéalement seulement un ou deux groupes de relecteurs.
Si un découpage crée une dépendance (par exemple, 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. Noter ceci explicitement.
Chaque PR doit être fusionnable indépendamment vers main — pas d'imports cassés, pas de symboles manquants. Les alias rétro-compatibles et les stubs de ré-export dans la première PR peuvent le rendre possible.

Présenter le découpage proposé sous forme de tableau :

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

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

3. Exécuter le découpage (après approbation de l'utilisateur)

Pour chaque nouvelle PR :

Créer une nouvelle branche à partir de la base appropriée (main, ou la branche d'une PR dépendante).
Extraire les changements pertinents : git diff upstream/main..<source-branch> -- <file paths> | git apply.
Mettre en staging, committer avec un message clair, et pousser vers le fork de l'utilisateur.
Créer la PR en tant que brouillon (selon les directives de contribution du dépôt).
Si la PR originale doit être réduite en portée, confirmer avec l'utilisateur avant de forcer la poussée.
Signaler toutes les URLs de PR une fois terminé.

Recommandations importantes

Toujours créer les PR en tant que brouillons et pousser vers le fork de l'utilisateur, jamais directement vers upstream.
Les changements rétro-compatibles (alias, ré-exports, shims de dépréciation) doivent aller dans la première PR afin que les PR suivantes puissent en dépendre.
Les fichiers de test doivent aller avec le code de production qu'ils testent, pas dans une PR distincte.
Préférer un seul commit propre par PR divisée plutôt que de rejouer l'historique des commits originaux.
Si un fichier est difficile à catégoriser (par exemple, il touche deux groupes), demander à l'utilisateur dans quelle PR il devrait aller.
Si l'utilisateur GitHub actuel n'est pas l'auteur de la PR originale, la description de chaque nouvelle PR doit créditer explicitement l'auteur original (par exemple, « Changements originaux par @<author> dans #<number> »).

split-pr