KDE est un projet de logiciel libre historiquement centré autour d'un environnement de bureau pour systèmes UNIX. Le projet dispose d'une communauté de logiciels libres et open source – de plus de 2700 artistes, concepteurs, programmeurs, traducteurs, rédacteurs et autres contributeurs dans le monde entier – dédiée à la création d’une expérience informatique conviviale. L’année dernière, la communauté KDE a annoncé la décision initiale de migrer vers GitLab afin d’apporter aux contributeurs des options supplémentaires à une infrastructure plus accessible, des outils rationalisés et un canal de communication ouvert en upstream sur GitLab. Lundi, GitLab a annoncé que KDE a officiellement terminé la première phase de sa migration, et les contributeurs ont commencé à utiliser la plateforme GitLab quotidiennement.KDE est une communauté internationale qui crée des logiciels à code source ouvert pour les ordinateurs de bureau et les appareils mobiles. Les logiciels de KDE sont compatibles avec de nombreuses plateformes, dont GNU/Linux, FreeBSD, Windows, macOS et Android. La communauté crée et maintient plus de 200 applications et d'innombrables add-ons, plugins et Plasmoids, plus de 1000 dépôts, plus de 80 framework pour les développeurs Qt et plus de 2600 projets. Le logiciel KDE est traduit dans plus de 100 langues pour permettre une vaste portée mondiale, selon un article de blog publié lundi par GitLab.
GitLab est la plateforme DevOps livrée en une seule application. Aleix Pol, président de KDE e.V., une organisation à but non lucratif qui représente la communauté KDE, a donné quelques objectifs de l’adoption de la plateforme :
« Adopter GitLab a été comme une étape naturelle depuis que l'opportunité a été présentée. Simplifier l'intégration de nouveaux contributeurs est l'un de nos principaux objectifs au sein de la communauté KDE. Pouvoir permettre aux contributeurs du projet de participer facilement à la manière dont les produits qu'ils maintiennent sont testés et livrés sera certainement un tournant pour notre écosystème », a-t-il déclaré, selon le billet de GitLab.
« En utilisant une plateforme offrant une interface et un flux de travail que la plupart des développeurs de logiciels libres connaissent aujourd'hui, nous sommes convaincus que nous abaissons la barre pour que de nouveaux contributeurs nous rejoignent, et nous fournissons les bases pour que notre communauté s'agrandisse dans les années à venir », a ajouté Neofytos Kolokotronis, membre du conseil d'administration de KDE e.V. et membre principal de l'équipe KDE Onboarding Initiative.
En septembre, Lydia Pintscher, présidente de KDE e.V., avait déclaré : « Pour une communauté ouverte comme KDE, il est essentiel de disposer d'une infrastructure conviviale et facile à utiliser. Nous avons passé ces deux dernières années à réduire de manière significative les barrières à l’entrée dans KDE. Passer à GitLab est une étape majeure de ce processus ».
KDE utilise l'édition communautaire du GitLab en raison de son engagement en faveur de l'open source. Selon Gitlab, les membres de l’équipe KDE ont activement collaboré avec ceux de l'équipe GitLab tout au long de la migration.
« Les valeurs de collaboration et de transparence de GitLab rayonnent vraiment au travers », a déclaré Neofytos. « Nous apprécions leur ouverture à accepter les demandes de fusion des membres de la communauté et à considérer les propositions de nouvelles fonctionnalités. Nous avons eu une grande expérience jusqu'à présent en collaborant avec les membres de la communauté GitLab et les membres de l'équipe GitLab - des développeurs aux responsables de programmes en passant par les propriétaires de produits ».
Comment la communauté KDE en est-elle arrivée là ?
C’est après une série de plusieurs étapes que l'équipe KDE a pris la décision de migrer vers la plateforme GitLab. KDE a formé dès le départ une équipe de migration, KDE Onboarding Initiative, qui a travaillé avec l'équipe système KDE Sysadmin pour effectuer une étude approfondie des fonctionnalités de la plateforme GitLab. Elles ont comparé les besoins de la communauté avec les fonctionnalités de GitLab. Ensuite, elles ont ensuite créé un processus qui permet à KDE d'exécuter de courts cycles de tests avec certains projets, de documenter le processus et de fournir un retour d'information à la communauté.
« La migration a commencé par le déplacement de quelques équipes KDE plus petites et plus agiles qui étaient très intéressées par les tests et les retours d'information. Une fois ce cycle terminé avec succès, KDE a commencé à migrer des équipes avec une base de code plus importante et plus de contributeurs. Une fois que tous les problèmes majeurs ont été résolus, ils ont procédé au changement final pour tous les projets restants qu'ils prévoyaient de migrer », lit-on dans le l’article de GitLab.
L’équipe KDE a également impliqué la communauté dans la prise de décision dès le début, lit-on, l’a tenue informée de chaque phase de la migration, et toutes les questions et préoccupations ont été répondues et traitées de concert avec elle. « C'était un changement majeur pour nous, mais nous sommes très satisfaits de la façon dont notre communauté a collaboré sur de longs fils de discussion. Nous sommes convaincus qu'en travaillant ensemble, nous avons pris les meilleures décisions au fur et à mesure que nous avancions », a déclaré Neofytos.
Les défis et solutions en matière de migration
Selon GitLab, le plus grand défi auquel a fait face l’équipe KDE était le volume de données que la communauté traitait et la façon dont il était intégré dans les nombreux outils utilisés (y compris Phabricator). Pour relever ce défi, KDE a décidé d'aborder la migration par étapes plutôt que de la faire d'un seul coup, c’est ainsi que l’équipe a pu traiter séparément différents types de données, tels que les dépôts et les tâches.
« KDE a développé des outils personnalisés pour faciliter les mises à jour en masse tout au long du processus de migration. Ces outils permettent de définir le nom, la description et l'avatar des projets ainsi qu'un certain nombre de paramètres, par exemple les branches protégées et les méthodes de fusion. En utilisant ces outils personnalisés pour les mises à jour en masse, KDE a également pu éviter d'accorder l'accès au mainteneur à des contributeurs individuels », selon GitLab. KDE n'autorise l'accès à ces derniers qu’aux sysadmins en fonction de leur politique d'accès et de permissions ».
Pour s’assurer que certains contrôles et actions se poursuivent correctement après la migration vers Gitlab, KDE a porté des git hooks personnalisés. Il s'agit notamment de vérifications pour s'assurer que les encodages des fichiers correspondent aux exigences de KDE et que les bogues de leur installation Bugzilla ont été résolus selon les besoins. Afin de soutenir sa communauté de traduction, qui utilise toujours Subversion dans son flux de travail, KDE a également construit des outils pour exporter des clés SSH depuis GitLab afin d'éviter de devoir les mettre à jour à deux endroits. KDE a également ajusté les outils utilisés pour construire et développer le logiciel KDE afin de les rendre compatibles avec la nouvelle structure de dépôt de GitLab.
Comment structurer ses groupes pour permettre au mieux les flux de travail de la communauté et lui permettre de respecter les politiques était un autre défi que KDE devait relever. Pour y parvenir, KDE a créé une série de groupes au niveau supérieur de GitLab pour fonctionner en tant que catégories, et a classé dans chacune de ces catégories ses 1 200 dépôts. Selon GitLab, KDE a mis en place cette stratégie architecturale pour aider les développeurs à avoir un aperçu plus facile des demandes de fusion pour les catégories qui les intéressent le plus. En ce qui concerne les permissions, KDE utilise un seul master group "KDE Developers" pour gérer les niveaux d'adhésion et de permission, tous les concernés y ayant accès en tant que "développeur".
Selon GitLab, après le travail de préparation, la migration proprement dite a pris environ une journée, et jusqu’à présent, KDE a surmonté la plupart des obstacles à la migration. Mais il reste encore quelques défis à relever qui se résument en deux phases : l'intégration continue (CI) et la gestion des tâches pour les développeurs sur GitLab.
Source : GitLab
Et vous ?
Que pensez-vous du choix de GitLab par KDE ? Êtes-vous utilisateur des outils développés par KDE ? Pensez-vous que KDE a bien fait de migrer vers GitLab ? Ou préfériez-vous qu’il choisisse une autre plateforme ?Voir aussi :
KDE adopte GitLab pour apporter des options supplémentaires à une infrastructure plus accessible aux contributeurs, des outils rationalisés et un canal de communication ouvert en upstream sur GitLab Les développeurs de KDE commencent à réfléchir aux KDE Frameworks 6, qui augure d'un grand nettoyage des API KDE Connect supprimé de Google Play pour violation d'une politique sur les SMS, pourtant l'application en a besoin pour offrir une expérience complète Une faille dans KDE permet de corrompre un ordinateur sans même ouvrir le fichier malicieux, un correctif doit être mis en place rapidement