Définition d'un workflow

Il faudrait définir la façon dont les ajouts/modifications peuvent être faits au niveau du code, des datas et des assets graphiques, définir la façon dont on peut committer (histoire d'avoir des branches utiles et pas plein de scories qui trainent), peut-être une branche claire qui permette aux mainteneurs de paquets de savoir qu'ils peuvent s'appuyer dessus sans s'attarder sur les branches de développement.

Ma proposition se base sur Git, et son interface graphique GitLab, et le workflow Gitflow.

De ce fait, j'ai prévu d'avoir 4 branches principales :

1. Panka : Branche stable
2. Lirria : Branche de test (Béta)
3. Spofu : Branche de développement (Alpha) ← C'est ici que l'on va faire nos modifications
4. Upstream : Branche synchronisé avec Ryzomcore, qui nous servira à faire nos merges et cherry-pick.

Il y aura également des branche secondaires (propre à Gitflow) :

• Branches “hotfix/unFix” : corrections de bugs urgents, qui seront merge avec les 3 branches principales.
• Branches “feature/uneFeature” : travail sur les features propres à Khanat, requérant des modifications dans le code qui ne seront pas forcément envoyé à upstream (Ryzomcore)

Avantages :

• Plus de clarté (on n'a plus toutes les branches inutiles de Ryzomcore)
• Une interface graphique qui fait également la gestion des bugs, des merges, des milestones, etc.
• Gestion des droits plus aisé (et compatible LDAP)
• Des addons bien pratiques (CI, Wiki, etc…)
• Snippets (Bouts de codes hors dépôt)
• Gestion des archives des releases (plus facile à DL)

Inconvénients :

• Seulement en Anglais
• Développement un peu plus contraignants (fini de push sauvages )

1. Export des dépôts Mercurial vers Git [OK]
2. Synchronisation manuel de Ryzomcore:develop avec Khaganat:upstream [OK]
3. Synchronisation automatique de Ryzomcore:develop avec Khaganat:upstream [En cours : test]
4. Mise en place d'une instance GitLab de test chez nous [Planification]
5. Test de l'instance de test [En attente]
6. Formation des contributeurs (s'appuyer sur les cours en ligne https://www.grafikart.fr/formations/git )

• Connaissances de base de Mercurial, Git, ou tout autre système de gestion de version.

Dremor, qui s'occupe des paquets, aurait besoin de savoir où exactement obtenir les données à empaqueter, cela doit être défini clairement.

Une liste des branches serait également utile, avec des sandbox pour ceux qui veulent par exemple.

Enfin, il faudrait rédiger tout cela clairement et proprement pour faciliter et aider les contributions. Des schémas détaillés, des instructions claires et des notices sur les différents dépôts aideraient.
C'est la page Recupérer les données : Mercurial, Git qu'il faudrait refaire

Pour réfléchir à l'usage (ou non) de GitFlow : Une critique avec sa suite. Toute la question semble être de voir si on est plutôt 'merge' ou plutôt 'rebase' car cela affecte l'organisation générale (la première option = gitflow,la seconde donnant un historique plus linéaire). Il y a des éléments de réflexion à récupérer dans Bien utiliser Git merge et rebase.

Il faut aussi tenir compte du fait que nous aurons une branche upstream qui sera issue du code Mercurial de Bitbucket pour récupérer les commits de RC.

Documentation possible sur Git:

• Le lire de référence, en français (quelques parties demeurent en anglais) ;
• Formation Git vidéo en ligne par GrafikArt
• GitKraken, un utilitaire graphique très complet pour Git (expliqué en français dans une vidéo GrafikArt). Pas libre mais multiplateforme.
• Un site formation dédié à Git, avec la possibilité de faire des vrais stages pro de formation (avec les prix en fonciton), mais pas mal de tutos très techniques et très précis.

Documentation sur GitFlow:

• Une page récapitulant les commandes de façon claire et illustrée.