Bonjour Nal,
Je l'avais mentionné dans une dépêche à propos de Haiku, mais cet outil mérite au moins son propre journal.
Donc au départ, il y a Gitstats. C'était un outil simple en Python pour générer quelques pages HTML montrant l'activité d'un projet Git: nombre de commits par mois, contributeurs les plus actifs, etc. C'est du Python2, tout est en vrac dans un seul fichier, ça génère du vieux HTML, et surtout, ça n'est plus maintenu depuis 5 ans.
Maintenant, il y a Repostat, fork du précédent, réécrit en Python3, avec du HTML un peu moins moche. Ça utilise libgit2 pour analyser le dépôt Git, Pandas pour analyser les données, Jinja pour générer du HTML à partir de templates, et NVD3 pour faire des graphes interactifs en Javascript (cette dernière partie développée par moi-même).
L'utilisation est assez simple, il faut un checkout d'un dépôt git et un fichier json qui ressemble à ça:
{
"max_recent_tags": 0,
"max_plot_authors_count": 10,
"max_authors": 25,
"time_sampling": "Q",
"colormap": "plasma",
"orphaned_extension_count": 2
}
On lance la commande:
repostat --config-file config.json --no-browser --with-index-page --copy-assets chemin_du_depot chemin_sortie_html
Quelques exemples:
- Statistiques de Haikuports
- Statistiques de SerenityOS
- Statistiques de Haiku (certains graphes qui prennent trop de temps à générer sont désactivés)
- Statistiques de Repostat (avec la configuration par défaut, qui a un thème moins coloré pour les tableaux)
Cela fournit un assez bon remplacement aux "Insights" de Github ou à ce que fait Openhub, aucun des deux n'étant libre.
Je suis intéressé de voir les statistiques sur vos projets Git préférés si vous les générez.
Je suis aussi intéressé si vous vous lancez dans des améliorations du projet. En particulier, si quelqu'un pouvait s'occuper de mettre en place un cache des résultats d'analyse pour que je sois pas obligé de rescanner les 10 ans d'existence du dépôt de Haiku à chaque fois que je veux mettre ma page de statistiques à jour, ça serait super. Mais y'a aussi plein de choses à faire pour ajouter des analyses supplémentaires et des nouveaux graphiques :) Ou si vous êtes web designer et que vous voulez rendre le tout un peu plus présentable/moderne/arrondi/brillant/… .
Voilà, c'est tout pour aujourd'hui, amusez-vous bien!
# Mais qu'est-ce que c'est-il donc ?
Posté par ymorin . Évalué à 5.
Intéressant, merci.
Il y a une métrique dont la signification m'échappe :
"Lost knowledge" ratio. Autant je comprends le sens des mots, comment est-elle calculée ? Et comment peut-on l'interpréter ?Merci ! ;-)
[^] # Re: Mais qu'est-ce que c'est-il donc ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Si je me souviens bien c'est inspiré de cet article: https://www.feststelltaste.de/identifying-lost-knowledge-in-the-linux-kernel-source-code/ et ce doit donc être le nombre de lignes de code qui n'ont pas été modifiées depuis plus de 6 mois
[^] # Re: Mais qu'est-ce que c'est-il donc ?
Posté par claudex . Évalué à 5.
Je ne sais pas ce que vous en pensez, mais je trouve ça court 6 mois, sauf s'il y a un turnover assez important dans le projet. J'aurais plutôt mis 2 ans.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mais qu'est-ce que c'est-il donc ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Quand on me demande ce à quoi je pensais quand j'ai écrit un bout de code il y a plus de 1 ou 2 mois, c'est difficile pour moi de me souvenir dans quel contexte c'était. Mais cela dépend des gens, de l'organisation des projets, etc. De toutes façons cette métrique n'est pas forcément pertinente: j'espère bien qu'aucun projet n'est complètement réecrit tous les 6 mois ou même tous les 2 ans! C'est assez normal d'avoir du code stable qui n'a pas besoin de bouger, non?
C'est indépendant du turnover, ça mesure surtout le fait que les gens oublient les détails sur ce qu'ils ont fait (même s'ils sont toujours là pour essayer de répondre aux questions).
Je suppose qu'il est possible sans trop complexifier le truc de faire une analyse par tranches: % du code qui a moins de 6 mois, moins de 2 ans, etc. Ça ferait encore un joli graphe à rajouter :)
Pour mesurer la perte de connaissance liée au turnover il faudrait mettre en relation les "knowledge carriers" (nombre de lignes de code qu'une personne est la dernière à avoir modifiées) avec la date du dernier commit par la personne en question?
[^] # Re: Mais qu'est-ce que c'est-il donc ?
Posté par claudex . Évalué à 3.
Si je prends le temps de réfléchir, j'arrive à me souvenir pourquoi j'ai écrit le bout de code il y a 6 mois. Il y a deux ans, c'est plus rare.
J'espère
Je voulais dire que si le turnover est élevé, après 6 mois sans y toucher, plus personne ne sait ce que le code fait là.
Je pensais à ça aussi.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mais qu'est-ce que c'est-il donc ?
Posté par Guillaum (site web personnel) . Évalué à 6.
Une bonne solution pour avoir 0 à ce paramètre c'est de changer tous les mois les paramètres du formatage de code et de reformater toute la codebase.
Plus de perte de connaissance.
[^] # Re: Mais qu'est-ce que c'est-il donc ?
Posté par steph1978 . Évalué à 2. Dernière modification le 08 décembre 2020 à 22:55.
Il y avait un indice dans les exemples : indicateur pastèque:
# Merci !
Posté par Florent Fourcot . Évalué à 4.
J'étais très triste que gitstats ne soit plus maintenu, ça fait plaisir de retrouver le même usage, en mieux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.