A voir si ça fonctionnera concrètement vu la complexité du code et des dépendencies imbriquées mais la meilleure manière de commencer je pense que c'est :
se répartir le main.c en 4
chaque personne itère sur sa partie de code
si c'est une une fonction hard / une fonction système (cad qui peut être directement remplacée par une fonction de la raspberryPialors
remplacer directement
sinon si c'est donc une fonction applicative f qui se trouve dans le main.c
explorer la fonction en profondeur pour trouver les fonctions systèmes hard à remplacer et la traduire
sinon(c'est donc une fonction applicative f qui se trouve dans un module autre que le main
ajouter une issue sur Github indiquant que la fonction f est en court d'être portéeOuvrir une branche (création via github) correspondant à cette issueTraduire la fonction f sur cette brancheUne fois f traduite, soumettre une Pull Request pour intégrer la traduction de la fonction à la branche #6 **
Principe
L'idée comme ça c'est qu'on puisse commencer à se répartir le main tout en évitant de se retrouver à être plusieurs à porter la même fonction en même temps. D'où l'idée et la contrainte de lever une issue Github à chaque fois qu'on commence à travailler sur une fonction qui n'est pas dans le main (pour indiquer aux autres qu'on est en train de travailler dessus).
Et l'idée de soumettre des Pull Requests dès que le portage de ces fonctions est terminé pour ne pas avoir un nombre énorme de branches, et pour que ces fonctions puissent être rapidement utilisées par les autres.
Précisions supplémentaires
A voir si ça fonctionnera concrètement vu la complexité du code et des dépendencies imbriquées mais la meilleure manière de commencer je pense que c'est :
si
c'est une une fonction hard / une fonction système (cad qui peut être directement remplacée par une fonction de la raspberryPialors
sinon si
c'est donc une fonction applicativef
qui se trouve dans le main.csinon
(c'est donc une fonction applicativef
qui se trouve dans un module autre que le mainPrincipe
L'idée comme ça c'est qu'on puisse commencer à se répartir le main tout en évitant de se retrouver à être plusieurs à porter la même fonction en même temps. D'où l'idée et la contrainte de lever une issue Github à chaque fois qu'on commence à travailler sur une fonction qui n'est pas dans le main (pour indiquer aux autres qu'on est en train de travailler dessus). Et l'idée de soumettre des Pull Requests dès que le portage de ces fonctions est terminé pour ne pas avoir un nombre énorme de branches, et pour que ces fonctions puissent être rapidement utilisées par les autres.
Ressources basiques
https://code.visualstudio.com/blogs/2020/05/06/github-issues-integration
https://github.blog/2019-01-07-create-pull-requests-in-vscode/
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
Schéma général du portage
Répartition du main
J'ai pas cherché à trop faire en fonction de la difficulté ou autre, j'ai fait simple :
Ressource sur la STM32
https://moodle.insa-toulouse.fr/course/view.php?id=79
Les 3 premiers PDFs sont super importants. Les autres ressources peuvent être interessantes mais pas indispensables.