• [^] # Re: Fréquence de commits un peu exagérée

    Posté par (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 5. Dernière modification le 09 août 2018 à 23:18.

    "22 commits par jour"
    [...]
    Tu parles de "depuis 2.10.2" et je ne sais pas quand tu as fait le calcul

    Je ne me souviens plus du calcul exact de l'époque mais je peux en refaire un.
    En gros, je regarderais les commits faits entre GIMP 2.10.2 et 2.10.4, et ce, sur master, car c'est là où se passe vraiment le développement (pas sur la branche gimp-2-10 en particulier qui ne contient que les backports pour la série stable).

    Sur master, y a un tag GIMP_2_10_2 mais pas GIMP_2_10_4 car on a créé la branche gimp-2-10 justement à la sortie de GIMP 2.10.2 (donc c'est là où les 2 branches ont commencé à diverger). Pour le commit d'arrêt, je vais donc prendre un commit qui correspond à la date de sortie de GIMP 2.10.4, soit le 2018年07月04日. Je prends le dernier commit à cette date. Note que ce n'est probablement pas le calcul que j'avais fait à l'époque, car j'imagine que j'avais pris HEAD qui était sûrement différent à l'époque (soit un peu avant, soit un peu après la sortie. Je ne suis pas sûr quand j'ai démarré cette dépêche collaborative). Quoiqu'il en soit, voyons le nombre de commits:

    $ git log GIMP_2_10_2..dc6c14c29fab25f3de87e1d0eaf4e761bdfd698e^ --oneline |wc -l
    972
    

    Comme il s'agit d'une période de 45 jours, je fais une moyenne, soit: 972 / 45 ≈ 21,6. Voilà (avec un arrondi, ça fait 22 ;p).

    Ensuite soyons clair: GIMP 2.10.2 est le moment où on a divergé vers le port GTK+3, comme je viens de le dire, donc ça veut notamment dire qu'on a mergé tout le travail fait sur GTK+3 (dont la majorité avait été faite ce même avril/mai, après la sortie de GIMP 2.10.0!) d'un seul coup. En un sens, ça a clairement boosté les statistiques. D'un autre côté, tant qu'on ne merge pas une branche de fonctionnalité, elle ne rentre dans aucune statistique. Faut bien qu'elle le rentre un jour (de même que j'ai des dizaines de commits qui attendent dans des branches de fonctionnalité en cours, et un jour, je les verserai dans master d'un coup, mais en attendant, c'est comme si ils n'existaient pas). De toutes façons, il y avait clairement un moment, qui correspond à la sortie de GIMP 2.10.0 où on a vraiment eu un gros pic de contributions.

    Si maintenant tu remontes plus loin, par exemple le début d'année, comme tu le proposes, on a une moyenne à 11 commits par jours:

    $ echo $(( `git log --oneline --since=2018年01月01日 |wc -l`/((`date -d "2018-08-09" +%s` - `date -d "2018-01-01" +%s`)/(60*60*24)) ))
    11
    

    "plusieurs années que le développement est aussi actif"

    De manière générale, il y a forcément des hauts et des bas dans le développement. Surtout que comme on est 3 à faire la plupart des commits, forcément il suffit qu'il y ait une période où l'un de nous est peu actif pour que les stats baissent (par exemple pour le mainteneur, c'est souvent les fins d'année où il a moins le temps de contribuer car il a un commerce), de même qu'y a des périodes où tout le monde s'active. Quand je dis qu'on est très actif depuis des années, ça veut pas dire qu'y un taux constant de contributions à tout moment (ce serait pas humain!). D'ailleurs, ailleurs dans un commentaire, je dis même que notre développement s'accélère au contraire (ce qui ne veut pas dire que ça ne va pas se calmer à un moment, et puis de toutes façons, il y a des limites humaines à notre rythme de contributions!). Voilà, donc en gros, faut pas non plus s'attacher au mot près. Je donnais les stats entre 2.10.2 et 2.10.4, qui étaient effectivement de 22 commits par jour en comptant dans git, et c'était effectivement un très gros pic.

    Enfin les stats, c'est aussi beaucoup du "marketing", soyons clair. De toutes façons, on peut faire dire beaucoup de choses aux nombres, on le sait tous. Rien que le choix d'unités est sujet à critique. Un commit, est-ce vraiment un critère adéquat? Faut-il compter le nombre de lignes à la place? Compte-t-on alors les lignes de commentaires (important aussi) ou juste le code pur et dur? Et qu'en est-il de ceux qui ont un code plus concis ou plus élagué (par exemple déclaration et définition sur des lignes distinctes, etc.)? Comment compte-t-on le temps de recherche, diagnostic, lecture de docs? Le temps pris pour des choses (importantes) autre que du code (écriture de news, docs, etc.), même? D'ailleurs peut-on même simplement compter le temps passé par les contributeurs pour GIMP (réponse directe: non, c'est du logiciel libre, on sait pas combien de temps passe chacun), et alors qu'en est-il des gens simplement plus efficaces que d'autres? Etc. Etc. Etc.

    Ma conclusion, c'est que ce sont des stats. Les miennes étaient vraies (comme montrées plus haut) car notre branche master a réellement 22 commits par jour entre GIMP_2_10_2 et la sortie de 2.10.4. Ensuite ça vaut ce que ça vaut (pas grand chose, ou beaucoup, c'est selon).
    Là où je voulais en venir avec ces stats, c'est que c'est du développement vraiment très actif. Et d'ailleurs tu es d'accord sur ce point. :-)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]