La Fondation NetBSD annonce une nouvelle politique de développement : le code généré par un grand modèle de langage ou une technologie similaire (par exemple ChatGPT, GitHub Copilot) est présumé corrompu (c'est-à-dire dont le copyright n'est pas clair, qui ne correspond pas aux objectifs de licence de NetBSD) et ne peut pas être livré dans NetBSD.NetBSD est un système d'exploitation Unix libre et gratuit basé sur la Berkeley Software Distribution (BSD). Il continue d'être activement développé et est disponible pour de nombreuses plateformes, y compris les serveurs, les ordinateurs de bureau, les appareils portables et les systèmes embarqués. Le projet NetBSD met l'accent sur la clarté du code, une conception soignée et la portabilité sur de nombreuses architectures informatiques. Son code source est accessible au public et sous licence permissive.
La Fondation NetBSD annonce une nouvelle politique de développement : le code généré par un grand modèle de langage ou une technologie similaire (par exemple ChatGPT, GitHub Copilot) est présumé corrompu (c'est-à-dire dont le copyright n'est pas clair, qui ne correspond pas aux objectifs de licence de NetBSD) et ne peut pas être livré dans NetBSD.
Les directives de validation suivantes définissent les standards du projet pour les commits dans l'arbre des sources :
1. Ne livrez que le code qui vous est familier.
Si vous n'êtes pas sûr que le code que vous prévoyez de livrer est acceptable (par exemple, lorsque vous prenez du code qui a été soumis avec un rapport de problème), demandez à un développeur qui est familier avec cette partie du système de le réviser. Si vous êtes nouveau dans le projet, consultez votre sponsor.
2. Ne livrez pas de code corrompu dans le référentiel.
Si vous livrez du code qui n'a pas été écrit par vous-même, vérifiez que la licence de ce code autorise l'importation dans le dépôt des sources de NetBSD, et autorise la distribution libre. Vérifiez avec le ou les auteurs du code, assurez-vous qu'il est le seul auteur du code et vérifiez avec lui qu'il n'a pas copié d'autre code.
Le code généré par un grand modèle de langage ou une technologie similaire, comme Copilot de GitHub/Microsoft, ChatGPT d'OpenAI, ou Code Llama de Facebook/Meta, est présumé être du code corrompu, et ne doit pas être livré sans l'approbation écrite préalable du noyau.
3. Ne pas livrer de code provenant d'arbres étrangers.
Ne pas livrer de code provenant d'un arbre extrait de n'importe où sauf de cvs.NetBSD.org. Notez que tous les développeurs ont accès au service privé rsync-over-ssh sur cvs.NetBSD.org.
4. Plus vos changements sont intrusifs, plus le niveau d'approbation préalable requis est élevé.
- Les corrections "évidentes" peuvent être livrées sans aucune discussion ou révision préalable. (La définition de "évident" dans le projet GCC est : "ne peut susciter d'objection de la part de quiconque". Cette définition est adoptée ici)
- Tous les autres correctifs (c'est-à-dire les correctifs "non évidents"
doivent faire l'objet d'une revue. - L'implémentation de nouvelles fonctionnalités (significatives) nécessite une discussion préalable sur une liste de diffusion technique appropriée.
- L'ajout d'un paquetage complètement nouveau (par exemple openldap) nécessite une discussion préalable sur une liste de diffusion et l'approbation du noyau.
5. Ne livrez que le code que vous avez testé.
Assurez-vous que votre code fonctionne réellement comme prévu, en compilant et en exécutant le code affecté par votre changement avec les outils de votre système. Si vous avez modifié une page de manuel, assurez-vous que groff/nroff crée la page de manuel formatée que vous attendez.
Pour les commits normaux (vers le tronc), testez que votre code fonctionne sur -current. Avant de demander un pull-up vers une branche, testez les changements que vous demanderez à releng sur la branche de sortie correspondante.
Exécutez tous les tests pertinents à partir de /usr/tests ou idéalement toute la suite de tests. Les logs des tests automatisés sont actuellement disponibles. Les régressions à long terme (rupture de la compilation ou échec des tests) ne sont pas acceptables et les changements qui en sont la cause seront annulés si les régressions ne sont pas corrigées.
6. Regrouper les commits qui font partie du même correctif.
Le rototiling d'une variable make qui affecte 50 Makefiles devrait donner lieu à un commit pour tous ensemble.
7. Chaque commit devrait être un patch/fixe/addition/etc. séparé.
Ne corrigez pas 3 bogues avec le même commit et ne transformez pas cela en "Correction de quelques bogues". Corrigez-en un, testez, validez, faite le propre, répétez. Cela rend la vie infiniment plus facile à releng pour extraire les correctifs car souvent tout ne s'applique pas à une branche donnée.
8. Ne mélangez pas les correctifs de fonctionnalité ou de correction de bogues avec les mises à jour de l'espace blanc ou de la mise en page.
Faites-les séparément (en dehors de l'exigence générale que les changements soient faits de manière à ce qu'il soit facile de discerner ce que chaque correction a fait, comme décrit dans le point 6, il y aura des problèmes de remontée avec des fichiers largement modifiés de tronc->branche lorsque vous mélangez l'espace blanc avec des corrections de fonctionnalité).
9. Documentez clairement les raisons de vos changements dans le journal de livraison.
Détaillez dans une certaine mesure ce qui a été modifié et pourquoi. Cela n'a pas besoin d'être une revue de code/walkthrough mais cela devrait être informatif pour quelqu'un qui lit le journal et regarde le diff dans 6 mois. L'accent doit être mis sur le "pourquoi" puisque le public cible qui lit les journaux peut généralement comprendre le "quoi" en regardant les différences.
Si votre changement corrige un PR, documentez-le avec un message approprié. L'utilisation du modèle "PR category/bug-id" dans votre commit l'ajoutera également au rapport de problème correspondant dans la base de données des bogues.
10. Donnez le crédit approprié.
Si vous livrez du code qui a été soumis dans un PR, donnez le crédit approprié.
11. Ne revenez pas sur les modifications d'un autre développeur.
Si vous n'êtes pas d'accord avec le commit d'un autre développeur, ne l'annulez pas de votre propre chef. Contactez l'autre développeur et expliquez-lui les problèmes que vous rencontrez avec le commit en question. Demandez à l'autre développeur d'annuler les modifications au lieu de le faire vous-même.
Source : NetBSD Commit Guidelines
Et vous ?
Quel est votre avis sur cette nouvelle directive de NetBSD ?Voir aussi :
L'utilisation de l'assistant d'IA GitHub Copilot pour la programmation entraîne une baisse de la qualité globale du code et une quantité importante de code redondant, selon une étude Les développeurs utilisent l'IA pour déboguer leur code, des rapports de tests, et même créer des applications, mais ils sont confrontés a des biais et des erreurs, d'après Applause Revue de code : un guide en 5 étapes pour que vos collègues vous détestent par Mensur Durakovic