Collaborer sur le dépôt OpenNeL Khanat Code

Ce dépôt est celui qui contient tout le code nécessaire à la compilation du serveur, ainsi que des outils du système OpenNeL, appelé un temps Ryzom Core. Nous avons cessé d’utiliser le client, remplacé par un client développé sous le Godot Engine.

Pour commencer, il vous faudra forker le dépôt principal. Ainsi, vous aurez votre propre dépôt, sur lequel vous pourrez effectuer vos modification sans interférer avec le dépôt principal.

Pour cela, il vous suffit de clique sur le bouton suivant sur la page d’accueil du projet.

Vous serrez alors redirigé vers votre copie du dépôt.

Si vous êtes un développeur “officiel” (avec une autorisation d'accès dans le groupe Khaganat ) chez nous, vous aurez accès au dépôt principal sur notre GitLab : Khanat OpenNeL code .

Vous n'aurez pas à créer un dépôt personnel (sauf si vous en avez envie) pour pouvoir contribuer, il vous suffira de travailler sur des branches en interne.

Khanat utilise un workflow inspiré de Gitflow. De ce fait, il y a deux types de branches : principales et temporaires.

Les branches principales sont :

• Branche Master (aka Lirria) : Branche stable, où seul les hotfix et les nouvelles release sont autorisés à être mergés. Cette branche garantie une expérience sans (trop de) bugs, dans la mesure du possible.

• Branche Develop : Branche de dévellopement, dans laquelle les features terminés sont mergés, en vu des futures releases.

• Branche Ryzomcore : Branche suivant les modifications d'amont du projet RyzomCore. Elle permet de merger celle-ci avec notre propre code.

A cela s'ajoute des branches temporaires, ouvertes et fermés suivants les besoins:

• Branche Feature : C'est une nouvelle addition au code de Khanat, développée dans une branche séparé afin de réduire les risque d'introduction de bugs dans develop. Elle sera à merge sur la branche “develop”.
• Branche Release : Ce type de branche est spécifique au dépôt principal, et est crée quand toutes les feature prévu dans une nouvelle release ont été merge dans develop. Une fois cette branche créer, seul les bugfix y sont autorisés, jusqu'à ce qu'elle soit merge dans “lirria”, une fois considéré comme suffisamment stable pour la “production”.
• Branche Hotfix : C'est une branche ayant pour objectif de rapidement corriger un bug critique affectant Lirria. De ce fait, elle sera merge vers la branche “lirria”, ainsi que “develop”.

Les branches, que ce soit sur votre fork ou sur les dépôts officiels, doivent être nommé de la façon suivante:

• Branche Feature : Doit être nommée “feature/[numéro(s) de(s) (l')issue][nom de la feature sans espaces ni ponctuation]”
  • Exemple : “feature/57-69-75-nouveau-fichier-dintegration-continue”
• Branche Release : Doit être nommée “release/[futur tag]”
  • Exemple : “release/v0.2.0”
• Branche Hotfix : Doit être nommée “hotfix/[numéro du/des bug(s)]-[descriptif du/des bug(s) sans espace ni ponctuation]”
  • Exemple : “hotfix/33-empêcher-les-poisson-de-sortir-de-leau”

Une fois que vous considérez la feature que vous avez développé terminé, vous pouvez créer une Merge Request, à destination de Develop. Cette requête doit respecter ces impératifs :

• Le CI Gitlab doit pourvoir la compiler avec succès.
• La feature et son code doivent être documentée.
• La Merge Request doit clairement expliquer la feature (son utilisation, les test à effectuer, etc.)

Une fois un certain nombre de features sont mergés avec Develop, nous créons une nouvelle branche release. A partir de ce moment, seul les bugfix sont acceptés (code freeze).

Une fois le nouveau code testé, et les bugs corrigés, la release est tagué, et publié dans master.

Il arrive que des bugs critiques passe à travers les maillons du filet de la QA, c'est pourquoi il est parfois nécessaire de faire des “hotfix” (correction à chaud).

Pour cela, il faut faire une branche “hotfix” depuis master, y corriger le bug, puis le publier dans master.

Lorsqu'on a terminé une Feature, il faut faire une demande de Merge Request en expliquant en quoi la tâche est terminée et l'affecter à une autre personne même si on a la capacité de merger directement.

Cela permettra d'avoir un contrôle, ne serait-ce que formel, sur l'ajout.

On ne merge jamais soi-même directement sur Master.

De préférence à la la base TAF, créez les demandes d'ajout de features sur le système Gitlab de ce dépôt. Bien évidement, les Bugs liés à la programmation sont à signaler ici également.

De même, avant de commencer une tâche, créez une Issue que vous vous attribuez, comme ça vous pouvez numéroter la branche correctement et on sait que quelqu'un a commencé à travailler sur ce sujet.

Les travaux à faire, modifications de fichier, créations, doivent être indiqués en se servant du système d'Issues de ce dépôt : Issue sur Khanat OpenNeL code

Il suffit de cliquer sur :

Vous renseignez ensuite les différents champs.

Le titre doit être concis et le plus explicite possible.
Par contre, n'hésitez pas à être le plus précis possible dans la zone Description.

Il y a ensuite 3 zones de champs à renseigner :

• Assignee pour indiquer la personne à qui affecter la tâche ;
• Milestone qui désigne la version du projet pour laquelle ce travail devra être fait ;
• Labels permet de choisir des tags pour déterminer le genre de tâche ;
• Select due date propose de fixer une date de remise des travaux.

Dans le doute, n'indiquez rien dans ces quatre champs. De toute façon, tout est éditable a posteriori donc ce n'est pas grave si vous faites des erreurs ou n'êtes pas assez précis.

On se servira des mêmes milestones que pour les autres dépôts et secteurs de développement du projet, présentés sur la page milestones.

Nous n'utilisons pas de Tags sur ce dépôt Git pour le moment.

Les Labels doivent être génériques et permettre ainsi de regrouper par genre de compétence. Il est possible d'en créer lors de la génération d'une Issue si aucune ne convient mais cela peut être fait par la suite, surtout quand on est indécis.