Le jeu à des contributeurs divers et variés, qui modifient une base de code unique en y envoyant de petits patchs, modifiant le moins de ligne possible.
Du coup, on arrive à avoir une bonne idée rapidement et même sans comprendre le code de ce que fait le patch, grâce à son intitulé.
Comme ils "commitent" régulièrement leurs modifications, les conflits sont rares et simples à résoudre, encore une fois surtout grâce à l'intitulé des commits.
Si un contributeur fait "silence radio" ( en terme de modifications visibles du code, je parle ) pendant 1 mois, et modifie, disons, 100 lignes par jour ( pas énorme, je précise, 100 lignes par jour ). Comptons 20 jours de travail dans un mois. Ça 2000 lignes à lire, et à intégrer avec les modifications qui ont eu lieu entre temps.
A savoir que quand on travaille sur une ligne, un diff peut l'afficher de plusieurs façons différentes:
insertion de code: ligne ajoutée
suppression de code: ligne supprimée
modification de code: ligne ajoutée, puis ligne ajoutée
Pas forcément super lisible, surtout que parfois la modification est de l'ordre de 1 caractère sur une ligne de 60 caractères de large.
Et bien entendu, ces 2000 lignes ne sont pas monolithiques, mais éparpillées partout dans plusieurs fichiers. Vu le jeu, je dirai plusieurs dizaines de fichiers.
Ces modifications peuvent être de l'ordre du bug-fix et de l'ajout de fonctionnalités "simples", là, ça reste aisé: de petits blocs par-ci par-là. Mais ça peut aussi être structurel, comme 0AD est en alpha, l'API n'est pas stable.
Tout ça, ça rends difficile l'intégration du travail dans l'existant.
Pour finir, je doute très fortement que le patch se limite à "seulement" 2000 lignes changées entres autres parce que si j'ai bien compris il à bossé 6 mois ( donc déjà 12K lignes ).
Maintenant, j'insiste: le KLoC ( Kilo Lines of Code, milliers de lignes de code ) est une métrique complètement stupide et inutile, à destination des gens qui croient que plus il y a de lignes dans un programme, plus il y a de travail. En réalité, le plus dur est de faire du code simple.
[^] # Re: a propos du megapatch
Posté par freem . En réponse à la dépêche Dernières évolutions autour de 0 A.D.. Évalué à 5.
Le jeu à des contributeurs divers et variés, qui modifient une base de code unique en y envoyant de petits patchs, modifiant le moins de ligne possible.
Du coup, on arrive à avoir une bonne idée rapidement et même sans comprendre le code de ce que fait le patch, grâce à son intitulé.
Comme ils "commitent" régulièrement leurs modifications, les conflits sont rares et simples à résoudre, encore une fois surtout grâce à l'intitulé des commits.
Si un contributeur fait "silence radio" ( en terme de modifications visibles du code, je parle ) pendant 1 mois, et modifie, disons, 100 lignes par jour ( pas énorme, je précise, 100 lignes par jour ). Comptons 20 jours de travail dans un mois. Ça 2000 lignes à lire, et à intégrer avec les modifications qui ont eu lieu entre temps.
A savoir que quand on travaille sur une ligne, un diff peut l'afficher de plusieurs façons différentes:
Pas forcément super lisible, surtout que parfois la modification est de l'ordre de 1 caractère sur une ligne de 60 caractères de large.
Et bien entendu, ces 2000 lignes ne sont pas monolithiques, mais éparpillées partout dans plusieurs fichiers. Vu le jeu, je dirai plusieurs dizaines de fichiers.
Ces modifications peuvent être de l'ordre du bug-fix et de l'ajout de fonctionnalités "simples", là, ça reste aisé: de petits blocs par-ci par-là. Mais ça peut aussi être structurel, comme 0AD est en alpha, l'API n'est pas stable.
Tout ça, ça rends difficile l'intégration du travail dans l'existant.
Pour finir, je doute très fortement que le patch se limite à "seulement" 2000 lignes changées entres autres parce que si j'ai bien compris il à bossé 6 mois ( donc déjà 12K lignes ).
Maintenant, j'insiste: le KLoC ( Kilo Lines of Code, milliers de lignes de code ) est une métrique complètement stupide et inutile, à destination des gens qui croient que plus il y a de lignes dans un programme, plus il y a de travail. En réalité, le plus dur est de faire du code simple.