Vous arrive-t-il de « blâmer » (git-blame(1)) un fichier du noyau Linux et tomber sur le commit original de Linus 1da177e4c3f4 (“Linux 2.6.12-rc2”) ? Quand je tombe dessus, en général, je laisse tomber ma recherche car c'est un signe que je suis allé « un peu trop loin », et j'essaye de trouver la raison de la présence du code en réfléchissant un peu plus, sans autre indice.
Mais dernièrement, j'ai vraiment voulu savoir qui disait dans les sources de Linux que Van Jacobson se trompait dans son fameux papier du SIGCOMM en 1988 qui a inventé le TCP slow-start (“Congestion Avoidance and Control” http://ee.lbl.gov/papers/congavoid.pdf), le premier algorithme à réguler correctement l'Internet.
J'ai commencé par « blâmer » net/ipv4/tcp_input.c (c'est la sortie de :Gblame de vim-fugitive https://github.com/tpope/vim-fugitive par Tim Pope, en réalité) :
740b0f1841f6e 670 (Eric Dumazet 2014-02-26 14:02:48 -0800 |static void tcp_rtt_estimator(struct sock *sk, long mrtt_us)
^1da177e4c3f4 610 (Linus Torvalds 2005-04-16 15:20:36 -0700 |{
6687e988d9aea 555 (Arnaldo Carvalho de Melo 2005-08-10 04:03:31 -0300 | struct tcp_sock *tp = tcp_sk(sk);
740b0f1841f6e 673 (Eric Dumazet 2014-02-26 14:02:48 -0800 | long m = mrtt_us; /* RTT */
740b0f1841f6e 674 (Eric Dumazet 2014-02-26 14:02:48 -0800 | u32 srtt = tp->srtt_us;
^1da177e4c3f4 612 (Linus Torvalds 2005-04-16 15:20:36 -0700 |
^1da177e4c3f4 616 (Linus Torvalds 2005-04-16 15:20:36 -0700 | /* The following amusing code comes from Jacobson's
^1da177e4c3f4 617 (Linus Torvalds 2005-04-16 15:20:36 -0700 | * article in SIGCOMM '88. Note that rtt and mdev
^1da177e4c3f4 618 (Linus Torvalds 2005-04-16 15:20:36 -0700 | * are scaled versions of rtt and mean deviation.
e905a9edab7f4 564 (YOSHIFUJI Hideaki 2007-02-09 23:24:47 +0900 | * This is designed to be as fast as possible
^1da177e4c3f4 620 (Linus Torvalds 2005-04-16 15:20:36 -0700 | * m stands for "measurement".
^1da177e4c3f4 621 (Linus Torvalds 2005-04-16 15:20:36 -0700 | *
^1da177e4c3f4 622 (Linus Torvalds 2005-04-16 15:20:36 -0700 | * On a 1990 paper the rto value is changed to:
^1da177e4c3f4 623 (Linus Torvalds 2005-04-16 15:20:36 -0700 | * RTO = rtt + 4 * mdev
^1da177e4c3f4 624 (Linus Torvalds 2005-04-16 15:20:36 -0700 | *
^1da177e4c3f4 625 (Linus Torvalds 2005-04-16 15:20:36 -0700 | * Funny. This algorithm seems to be very broken.
^1da177e4c3f4 626 (Linus Torvalds 2005-04-16 15:20:36 -0700 | * These formulae increase RTO, when it should be decreased, increase
31f3426904e06 549 (Stephen Hemminger 2005-11-15 15:17:10 -0800 | * too slowly, when it should be increased quickly, decrease too quickly
^1da177e4c3f4 628 (Linus Torvalds 2005-04-16 15:20:36 -0700 | * etc. I guess in BSD RTO takes ONE value, so that it is absolutely
^1da177e4c3f4 629 (Linus Torvalds 2005-04-16 15:20:36 -0700 | * does not matter how to _calculate_ it. Seems, it was trap
^1da177e4c3f4 630 (Linus Torvalds 2005-04-16 15:20:36 -0700 | * that VJ failed to avoid. 8)
^1da177e4c3f4 631 (Linus Torvalds 2005-04-16 15:20:36 -0700 | */
4a5ab4e224288 692 (Eric Dumazet 2014-02-06 15:57:10 -0800 | if (srtt != 0) {
4a5ab4e224288 693 (Eric Dumazet 2014-02-06 15:57:10 -0800 | m -= (srtt >> 3); /* m is now error in rtt est */
4a5ab4e224288 694 (Eric Dumazet 2014-02-06 15:57:10 -0800 | srtt += m; /* rtt = 7/8 rtt + 1/8 new */
^1da177e4c3f4 637 (Linus Torvalds 2005-04-16 15:20:36 -0700 | if (m < 0) {
On tombe sur ce fameux commit. Je cherche alors un dépôt qui pourrait contenir l'historique précédent ; Thomas Gleixner a justement créé un dépôt contenant l'historique pré-git :
git remote add tglx-history git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
git fetch tglx-history
Et j'utilise alors la commande magique :
git replace 1da177e4c3f4 e7e173af42db
Le second SHA1 correspond à la pointe de cet ancien historique (on aura vérifié au préalable que ces deux arborescences correspondent exactement avec un "git diff 1da177e4c3f4 e7e173af42db", ou en vérifiant le SHA1 du tree avec un "git show --format=raw" de chacun des deux commits), et sera donc maintenant substitué à toute référence à 1da177e4c3f4.
Je re-blame :
740b0f1841f6e 670 (Eric Dumazet 2014-02-26 14:02:48 -0800 |static void tcp_rtt_estimator(struct sock *sk, long mrtt_us)
^7a2deb329241 418 (Linus Torvalds 2002-02-04 17:40:40 -0800 |{
6687e988d9aea 555 (Arnaldo Carvalho de Melo 2005-08-10 04:03:31 -0300 | struct tcp_sock *tp = tcp_sk(sk);
740b0f1841f6e 673 (Eric Dumazet 2014-02-26 14:02:48 -0800 | long m = mrtt_us; /* RTT */
740b0f1841f6e 674 (Eric Dumazet 2014-02-26 14:02:48 -0800 | u32 srtt = tp->srtt_us;
^7a2deb329241 420 (Linus Torvalds 2002-02-04 17:40:40 -0800 |
^7a2deb329241 421 (Linus Torvalds 2002-02-04 17:40:40 -0800 | /* The following amusing code comes from Jacobson's
^7a2deb329241 422 (Linus Torvalds 2002-02-04 17:40:40 -0800 | * article in SIGCOMM '88. Note that rtt and mdev
^7a2deb329241 423 (Linus Torvalds 2002-02-04 17:40:40 -0800 | * are scaled versions of rtt and mean deviation.
e905a9edab7f4 564 (YOSHIFUJI Hideaki 2007-02-09 23:24:47 +0900 | * This is designed to be as fast as possible
^7a2deb329241 425 (Linus Torvalds 2002-02-04 17:40:40 -0800 | * m stands for "measurement".
^7a2deb329241 426 (Linus Torvalds 2002-02-04 17:40:40 -0800 | *
^7a2deb329241 427 (Linus Torvalds 2002-02-04 17:40:40 -0800 | * On a 1990 paper the rto value is changed to:
^7a2deb329241 428 (Linus Torvalds 2002-02-04 17:40:40 -0800 | * RTO = rtt + 4 * mdev
^7a2deb329241 429 (Linus Torvalds 2002-02-04 17:40:40 -0800 | *
^7a2deb329241 430 (Linus Torvalds 2002-02-04 17:40:40 -0800 | * Funny. This algorithm seems to be very broken.
^7a2deb329241 431 (Linus Torvalds 2002-02-04 17:40:40 -0800 | * These formulae increase RTO, when it should be decreased, increase
31f3426904e06 549 (Stephen Hemminger 2005-11-15 15:17:10 -0800 | * too slowly, when it should be increased quickly, decrease too quickly
^7a2deb329241 433 (Linus Torvalds 2002-02-04 17:40:40 -0800 | * etc. I guess in BSD RTO takes ONE value, so that it is absolutely
^7a2deb329241 434 (Linus Torvalds 2002-02-04 17:40:40 -0800 | * does not matter how to _calculate_ it. Seems, it was trap
^7a2deb329241 435 (Linus Torvalds 2002-02-04 17:40:40 -0800 | * that VJ failed to avoid. 8)
^7a2deb329241 436 (Linus Torvalds 2002-02-04 17:40:40 -0800 | */
4a5ab4e224288 692 (Eric Dumazet 2014-02-06 15:57:10 -0800 | if (srtt != 0) {
4a5ab4e224288 693 (Eric Dumazet 2014-02-06 15:57:10 -0800 | m -= (srtt >> 3); /* m is now error in rtt est */
4a5ab4e224288 694 (Eric Dumazet 2014-02-06 15:57:10 -0800 | srtt += m; /* rtt = 7/8 rtt + 1/8 new */
^7a2deb329241 442 (Linus Torvalds 2002-02-04 17:40:40 -0800 | if (m < 0) {
Damned, on remonte jusqu'à 2002 seulement, l'année où le noyau est passé à Bitkeeper. Peut-on remonter encore plus loin ? Je ne trouve pas directement sur https://git.kernel.org/pub/scm/linux/kernel/git/ alors je demande à mon moteur de recherche, et je tombe sur une page de stack-overflow qui fait exactement ce que je voulais faire, même si elle est un peu ancienne : https://stackoverflow.com/questions/3264283/linux-kernel-historical-git-repository-with-full-history
En effet, git n'utilise plus les « graft » depuis quelques temps (cf. https://git.wiki.kernel.org/index.php/GraftPoint), et le dépôt de Dave Jones a bougé ; on fait donc :
git remote add davej-history git://repo.or.cz/davej-history.git
git fetch davej-history
git replace 7a2deb329241 379a6be1eedb
Bon, en réalité, 379a6be1eedb (2.4.0-prerelease) diffère un peu de 7a2deb329241 (qui doit être la 2.4.0, selon le Makefile), mais ça ira pour nous. Re-blâmons :
740b0f1841f6e 670 (Eric Dumazet 2014-02-26 14:02:48 -0800 |static void tcp_rtt_estimator(struct sock *sk, long mrtt_us)
27fc11ad19808 81 (Linus Torvalds 2007-11-23 15:10:34 -0500 |{
6687e988d9aea 555 (Arnaldo Carvalho de Melo 2005-08-10 04:03:31 -0300 | struct tcp_sock *tp = tcp_sk(sk);
740b0f1841f6e 673 (Eric Dumazet 2014-02-26 14:02:48 -0800 | long m = mrtt_us; /* RTT */
740b0f1841f6e 674 (Eric Dumazet 2014-02-26 14:02:48 -0800 | u32 srtt = tp->srtt_us;
1a92894a2b89e 132 (Linus Torvalds 2007-11-23 15:14:55 -0500 |
1a92894a2b89e 133 (Linus Torvalds 2007-11-23 15:14:55 -0500 | /* The following amusing code comes from Jacobson's
27fc11ad19808 85 (Linus Torvalds 2007-11-23 15:10:34 -0500 | * article in SIGCOMM '88. Note that rtt and mdev
27fc11ad19808 86 (Linus Torvalds 2007-11-23 15:10:34 -0500 | * are scaled versions of rtt and mean deviation.
e905a9edab7f4 564 (YOSHIFUJI Hideaki 2007-02-09 23:24:47 +0900 | * This is designed to be as fast as possible
27fc11ad19808 88 (Linus Torvalds 2007-11-23 15:10:34 -0500 | * m stands for "measurement".
564ea1ed16941 130 (Linus Torvalds 2007-11-23 15:13:08 -0500 | *
0f9cac5b27076 119 (Linus Torvalds 2007-11-23 15:12:38 -0500 | * On a 1990 paper the rto value is changed to:
0f9cac5b27076 120 (Linus Torvalds 2007-11-23 15:12:38 -0500 | * RTO = rtt + 4 * mdev
58243c28f5045 420 (Linus Torvalds 2007-11-23 15:37:53 -0500 | *
58243c28f5045 421 (Linus Torvalds 2007-11-23 15:37:53 -0500 | * Funny. This algorithm seems to be very broken.
58243c28f5045 422 (Linus Torvalds 2007-11-23 15:37:53 -0500 | * These formulae increase RTO, when it should be decreased, increase
31f3426904e06 549 (Stephen Hemminger 2005-11-15 15:17:10 -0800 | * too slowly, when it should be increased quickly, decrease too quickly
58243c28f5045 424 (Linus Torvalds 2007-11-23 15:37:53 -0500 | * etc. I guess in BSD RTO takes ONE value, so that it is absolutely
58243c28f5045 425 (Linus Torvalds 2007-11-23 15:37:53 -0500 | * does not matter how to _calculate_ it. Seems, it was trap
58243c28f5045 426 (Linus Torvalds 2007-11-23 15:37:53 -0500 | * that VJ failed to avoid. 8)
0f9cac5b27076 121 (Linus Torvalds 2007-11-23 15:12:38 -0500 | */
4a5ab4e224288 692 (Eric Dumazet 2014-02-06 15:57:10 -0800 | if (srtt != 0) {
4a5ab4e224288 693 (Eric Dumazet 2014-02-06 15:57:10 -0800 | m -= (srtt >> 3); /* m is now error in rtt est */
4a5ab4e224288 694 (Eric Dumazet 2014-02-06 15:57:10 -0800 | srtt += m; /* rtt = 7/8 rtt + 1/8 new */
480eec6cdddc4 442 (Linus Torvalds 2007-11-23 15:41:02 -0500 | if (m < 0) {
Rha, les dates ne sont pas bonnes… Bon, c'est expliqué dans un commentaire plus bas sur la page SO précédemment citée, à priori le travail de Dave Jones sur archive.org aurait les bonnes dates. Mais ça reste un découpage par release, même sur archive.org : on voit que le bout qui m'intéresse vient de la 1.3.63, mais pas précisément qui l'a écrit.
Du coup je cherche plus loin, et je tombe sur https://pdfs.semanticscholar.org/d449/a2b0223e39c2eb86b85b4ea28cf9a1b0275c.pdf, un papier qui décrit la migration du développement de Linux de CVS vers BitKeeper, et parle d'un dépôt CVS de David S. Miller pour sa branche netdev, qui est un développeur de longue date du noyau et mainteneur depuis des lustres de la partie réseau, qu'on peut trouver ici en version git : https://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git/
Bon, la branche n'étant pas la « principale » de Linus, on ne tombe pas exactement sur le même code, mais après quelques recherches d'approximation, je tombe sur e51d875ae7fd qui ressemble pas mal au 2.4.0 final :
git remote add davem-netdev-vger-cvs git://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git
git fetch davem-netdev-vger-cvs
git replace 7a2deb329241 e51d875ae7fd
Voyons ce que ça donne :
740b0f1841f6e 670 (Eric Dumazet 2014-02-26 14:02:48 -0800 |static void tcp_rtt_estimator(struct sock *sk, long mrtt_us)
67329859a6829 81 (davem 1996-02-25 06:24:52 +0000 |{
6687e988d9aea 555 (Arnaldo Carvalho de Melo 2005-08-10 04:03:31 -0300 | struct tcp_sock *tp = tcp_sk(sk);
740b0f1841f6e 673 (Eric Dumazet 2014-02-26 14:02:48 -0800 | long m = mrtt_us; /* RTT */
740b0f1841f6e 674 (Eric Dumazet 2014-02-26 14:02:48 -0800 | u32 srtt = tp->srtt_us;
002c9340aafc9 132 (davem 1998-03-14 06:09:54 +0000 |
002c9340aafc9 133 (davem 1998-03-14 06:09:54 +0000 | /* The following amusing code comes from Jacobson's
67329859a6829 85 (davem 1996-02-25 06:24:52 +0000 | * article in SIGCOMM '88. Note that rtt and mdev
67329859a6829 86 (davem 1996-02-25 06:24:52 +0000 | * are scaled versions of rtt and mean deviation.
e905a9edab7f4 564 (YOSHIFUJI Hideaki 2007-02-09 23:24:47 +0900 | * This is designed to be as fast as possible
67329859a6829 88 (davem 1996-02-25 06:24:52 +0000 | * m stands for "measurement".
9805f13373c65 130 (davem 1997-04-22 01:06:27 +0000 | *
2248761e5cfcb 119 (davem 1996-11-10 21:25:00 +0000 | * On a 1990 paper the rto value is changed to:
2248761e5cfcb 120 (davem 1996-11-10 21:25:00 +0000 | * RTO = rtt + 4 * mdev
bf439654ca139 420 (davem 2000-08-09 11:59:03 +0000 | *
bf439654ca139 421 (davem 2000-08-09 11:59:03 +0000 | * Funny. This algorithm seems to be very broken.
bf439654ca139 422 (davem 2000-08-09 11:59:03 +0000 | * These formulae increase RTO, when it should be decreased, increase
31f3426904e06 549 (Stephen Hemminger 2005-11-15 15:17:10 -0800 | * too slowly, when it should be increased quickly, decrease too quickly
bf439654ca139 424 (davem 2000-08-09 11:59:03 +0000 | * etc. I guess in BSD RTO takes ONE value, so that it is absolutely
bf439654ca139 425 (davem 2000-08-09 11:59:03 +0000 | * does not matter how to _calculate_ it. Seems, it was trap
bf439654ca139 426 (davem 2000-08-09 11:59:03 +0000 | * that VJ failed to avoid. 8)
2248761e5cfcb 121 (davem 1996-11-10 21:25:00 +0000 | */
4a5ab4e224288 692 (Eric Dumazet 2014-02-06 15:57:10 -0800 | if (srtt != 0) {
4a5ab4e224288 693 (Eric Dumazet 2014-02-06 15:57:10 -0800 | m -= (srtt >> 3); /* m is now error in rtt est */
4a5ab4e224288 694 (Eric Dumazet 2014-02-06 15:57:10 -0800 | srtt += m; /* rtt = 7/8 rtt + 1/8 new */
893e1302654a9 442 (davem 2000-12-13 04:10:12 +0000 | if (m < 0) {
OK, beaucoup de commits sont indiqués comme venant de davem même si ça n'est pas forcément lui, mais voici ce que dit le message de commit :
commit bf439654ca139cfdac75ec1fc357da5c9917c00a
Author: davem <davem>
Date: Wed Aug 9 11:59:03 2000 +0000
Merge in ANKs net-000808-23:20 patch.
Linus better eat this.
Mais qui est cet ANK ? Il a l'air d'être assez actif dans le réseau. Je vois dans un commentaire un lien vers ftp.inr.ac.ru pour iproute2, et là ça me revient à l'esprit : Alexey Kuznetsov ! Qui est un des auteurs principaux d'iproute2 et de pas mal de code IPv6 dans le noyau.
Bon, il est tard pour aller plus loin, il me restera à étudier le commentaire en question pour plus tard.
# Correction
Posté par claudex . Évalué à 10.
Je me suis permis de corriger le markdown du dernier commit qui déconnait un peu.
Merci pour le journal.
« 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: Correction
Posté par benoar . Évalué à 4.
Merci. Il y a également les deux derniers blame qui n'apparaissent pas pareil que les deux premiers. J'étais pressé et j'ai posté tel-quel.
Franchement j'ai horreur de markdown, j'ai toujours des incohérences incompréhensibles. Je fais toujours du ReST qui est beaucoup plus logique et vraiment puissant, tout en étant plus lisible. Pas étonnant que ça ait été le choix des devs noyau plutôt que du markdown…
[^] # Re: Correction
Posté par claudex . Évalué à 5.
Voilà c'est fait.
Souvent les erreurs viennent des 4 caractères pour indenter le code. Je préfère les ``` au début et à la fin du bloc de code.
« 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: Correction
Posté par benoar . Évalué à 3. Dernière modification le 19 septembre 2018 à 10:18.
Merci pour les corrections, c'est beaucoup plus lisible.
J'avais oublié les ```, en effet, ça semble plus simple.
[^] # Re: Correction
Posté par raphj . Évalué à 1.
Je ne sais jamais comment on fait pour mettre un code dans une puce ou dans une citation en Markdown et j'ai bien galéré sur mon dernier journal avec ça.
Dans une vie antérieure, j'ai conçu une syntaxe dans laquelle ça se passe comme ça :
Ou, si on veut être plus explicite :
Pour une citation :
Pour les titres, pas de caractères bizarres : un
=
au début de la ligne donne un titre de premier niveau, deux=
donnent un titre de deuxième niveau et il est également possible d'utiliser une notation sous forme de sections du genre :Et c'est d'ailleurs transformé en sections HTML. Les espaces de début de lignes dans les blocs de code sont détectés et supprimés, en conservant malgré tout l'indentation du code. Le code du document lui-même peut en conséquence être indenté.
On sort de l'esprit Markdown qui est censé être lisible tel quel, mais finalement ici on ne voit jamais que le résultat HTML et je préfère que ce soit facile à écrire et à comprendre plutôt que « plus ou moins naturel » à lire.
Je n'aime pas du tout Markdown non plus, et faire des contorsions pour écrire ce que je dois écrire. Je préfèrerais pouvoir rédiger dans un langage style (X)HTML (il n'est pas vraiment question d'utiliser autre chose y compris la syntaxe que j'ai mentionnée plus haut, elle aurait probablement les mêmes problèmes que je trouve à Markdown pour d'autres gens de toute façon). Les règles sont extrêmement claires et simples et il n'y a pas d'histoire de « Oh, la liste n'est pas reconnue comme une liste parce qu'elle n'est pas entourée de lignes vides », ou « Ah, j'ai trop indenté les tirets de cette liste, du coup elle est reconnue comme un bloc de code ». Ou « J'ai mis une nouvelle ligne entre deux items de la liste, donc c'est reconnu comme deux listes ». Tu veux écrire une citation ? Alors tu la mets entre
<citation>
et</citation>
. Aucun mystère ou comportement étrange pour quelqu'un qui n'a pas l'habitude.[^] # Re: Correction
Posté par BAud (site web personnel) . Évalué à 3. Dernière modification le 19 septembre 2018 à 15:28.
cela donnerait :
Pour une citation :
Voici ce que cette page disait :
tout est à base de ce qui est indiqué sur la page wiki aide-edition, le point important à retenir est qu'il faut souvent ajouter une ligne blanche préalable (et la prévisualisation permet d'essayer).
spoiler : utiliser ```bash en le faisant précéder d'une ligne blanche
[^] # Re: Correction
Posté par raphj . Évalué à 4. Dernière modification le 19 septembre 2018 à 17:04.
Merci pour l'aide-edition, mais dans ton message, les blocs de codes sont hors des puces, et d'ailleurs chaque puce est dans une liste différente. Voici ce que donne "Code source de la sélection" dans Firefox :
Y a-t-il moyen d'éviter ça ?
Peut-être que beaucoup pensent que je chipote mais j'attache de l'importance à ce genre de choses.
À la personne qui m'a moinsé : je suis intéressé par savoir ce j'ai écrit de gênant pour éviter de recommencer à l'avenir.
(edit: et effectivement j'avais réussi pour le code dans une citation, mais je n'avais pas trouvé la syntaxe que j'ai utilisée élégante / intuitive - je suppose que c'est une question de goût personnel, là on n'y peut pas grand chose)
[^] # Re: Correction
Posté par BAud (site web personnel) . Évalué à 4.
a priori non, en l'état, du fait qu'actuellement il faut ajouter une ligne blanche pour que le code soit pris en compte, ainsi que la liste à puce => peut-être faire évoluer le transcodage du Markdown.
la syntaxe pour le code dans une citation est élégant avec le Markdown je trouve 'fin bon, comme tu dis question de goût :
> Ce code ne fonctionne pas toujours comme attendu :
>
>```bash
> echo "$message"
>```
(tu noteras la fameuse ligne intercalaire…)
[^] # Re: Correction
Posté par raphj . Évalué à -2. Dernière modification le 20 septembre 2018 à 01:05.
Effectivement, l'évolution de la traduction Markdown -> HTML que tu mentionnes me paraît être une bonne idée. Je peux écrire une entrée dans le suivi pour ça si ça paraît utile à quelqu'un.
Ah, effectivement c'est élégant comme ça. Il me semble que j'avais trouvé une autre manière de faire (que je n'ai pas trouvé élégante) ou alors ma mémoire me fait défaut.
Bref, je ne suis pas fan du Markdown, peut-être en partie parce que je ne le pratique pas assez, mais trouver une syntaxe qui plairait à tout le monde est probablement une idée assez utopique de toute façon.
Sinon, est-ce que ça vaudrait le coup que je crée une entrée dans le suivi pour proposer une option qui permet à l'utilisateur de saisir un commentaire / un journal en HTML (à voir pour les dépêches et l'interaction que cette option pourrait avoir avec l'aspect édition collective des dépêches), quitte à ce que cet HTML soit épuré et transformé ? (pas d'utilisation de styles, de scripts, d'iframes, d'objets, toutes les balises fermantes correspondent à des balises ouvrantes et vice-versa). Quitte à ce que ce soit une option proposée à partir d'un certain karma pour limiter les éventuels problèmes de sécurité non anticipés que cela pourrait poser. Je n'ai aucune idée si ça a déjà été discuté par le passé.
Ça permettrait aux grincheux comme moi d'utiliser la syntaxe qu'ils / elles veulent pour rédiger, y compris l'HTML directement.
[^] # Re: Correction
Posté par raphj . Évalué à 1. Dernière modification le 20 septembre 2018 à 01:50.
Pour référence, voilà comment j'avais fait (sans les espaces en début de lignes, mais je ne sais pas comment citer correctement un code markdown pour produire un bloc de code) :
Et là, ce qui suit pète tout. Je passe deux lignes vides, puis j'indente une ligne avec 8 espaces, puis je passe une ligne vide et je commence à écrire "J'essaie de […]" :
[^] # Re: Correction
Posté par BAud (site web personnel) . Évalué à 3.
classiquement, il y a le code d'échappement
\
à placer aux endroits opportuns pour gêner la regexp et ne pas prendre en compte les codes markdown…m'enfin, t'inquiète, je suis un maniaque du bouton
Prévisualiser
pour m'assurer que cela s'affiche comme je m'y attends :-)Le mode de Markdown avec le préfixe par caractères espace est le plus embêtant àmha, 'fin celui qui m'embête le plus (et toi aussi, vu que ça n'indente pas). Donc, je ne cherche plus à indenter :p et, oui, la ligne préalable parfois ça marche, parfois pas… ou pas tout le temps O_o
Pour revenir sur un point que tu évoquais plus haut, pour la gestion des titres, il y a deux modes de fonctionnement :
c'est décrit sur https://linuxfr.org/wiki/aide-edition#titres
et il y a des fonctions cachées liées à des effets de bord des regexp… mais bon avoir fait du lex/yacc (rapidement remplacé par flex+bison…) à une époque où la seule doc' était la théorie des regexp / le code a dû irrémédiablement dédier une partie de mon cerveau a retenir les syntaxes de wiki o_O et trouver ce qu'on peut faire avec (ou pas).
[^] # Re: Correction
Posté par raphj . Évalué à 2.
Merci BAud de prendre tout ce temps à me lire et me répondre !
Je suis moi aussi un gros utilisateur du bouton prévisualiser et son utilisation obligatoire est une bonne chose.
[^] # Re: Correction
Posté par BAud (site web personnel) . Évalué à 3. Dernière modification le 21 septembre 2018 à 00:15.
ça existait à l'époque de templeet pour l'édition des dépêches quand j'étais modo, mais bon, c'était un peu le dernier recours…
# En fabriquer un dépôt git pour l'historique?
Posté par Babelouest (site web personnel) . Évalué à 10.
Une idée me vient à l'esprit en lisant ton journal.
Serait-ce un chouette projet pour la postérité de faire un repository git qui contiendrai tout l'historique du noyau linux disponible avec les métadonnées disponibles (date, qui a commité, commentaire, etc.)?
J'avoue, ca ressemble à un projet de moine archiviste qui n'est peut-être pas utile en soi.
Mais ca peut avoir de l'intérêt pour un éventuel chercheur/journaliste/curieux/insomniaque qui veut faire des statistiques ou des analyses sociales liées aux commits dans le code source du noyau, voire pour une autre raison qui m'échappe parce que liée à un domaine qui n'existe pas encore ou que je ne connais pas…
Je me fourvoie?
[^] # Re: En fabriquer un dépôt git pour l'historique?
Posté par Renault (site web personnel) . Évalué à 7.
Un peu comme https://www.softwareheritage.org/?lang=fr mais avec le lien entre les différents historiques du noyau ?
[^] # Re: En fabriquer un dépôt git pour l'historique?
Posté par AncalagonTotof . Évalué à 6.
Ou encore :
Gource / Linux (YouTube)
Ça sert à rien, mais c'est joli ;-)
[^] # Re: En fabriquer un dépôt git pour l'historique?
Posté par benoar . Évalué à 7. Dernière modification le 19 septembre 2018 à 08:23.
C'est un projet qui a été mené par Dave Jones, comme cité dans la page SO. Il a un dépôt du code utilisé :
https://github.com/kernelslacker/linux-historic-scripts
Et la page qui héberge le résultat :
https://archive.org/details/git-history-of-linux
Mais ça n'était pas satisfaisant pour moi, qui cherchait un découpage plus précis. Rechercher les patchs originaux de la branche de Linus n'est vraiment pas facile, mais ça serait en effet un travail intéressant, je pense.
[^] # Re: En fabriquer un dépôt git pour l'historique?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Au FOSDEM cette année il y avait une conférence sur un travail similaire pour les BSD, avec un dépôt git remontant jusqu'aux toutes premières versions d'UNIX des années 70 (dont certaines ont dû être récupérées à partir de listings sur papier).
[^] # Re: En fabriquer un dépôt git pour l'historique?
Posté par claudex . Évalué à 8.
Le lien: https://github.com/dspinellis/unix-history-repo
Il y a plusieurs branches en fonction des différentes versions mais ce n'est que pour FreeBSD (et ses ancêtres).
« 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
# Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par Dring . Évalué à 5.
Dans le développement du noyau, le rôle de l'intégrateur (ou mainteneur officiel) est clair : il reçoit les patchs, il les relit, les valide (ou non) et alors seulement ça rentre dans son repo git. C'est lui que git affiche, et si l'intégrateur a bien fait son travail, il montre l'auteur original dans le log du commit.
C'est plutôt logique : le "coupable" en cas de commit foireux est d'abord l'intégrateur qui a accepté le code, qui se retourne ensuite vers l'auteur original si besoin.
Perso, je vois ça comme une limite de la plupart des gestionnaires de configuration, mais ce n'est pas mon sujet du jour.
Maintenant, regardons comment git est (parfois) utilisé dans les grosses entreprises. Vous avez des équipes, chacune travaille sur un projet, composées de plusieurs développeurs, et en général un intégrateur. Les développeurs travaillent sur leur propre branche, et quand ils sont contents, ils envoient le tout à l'intégrateur, qui merge dans la branche principale. En général, c'est moins rigoureux que pour le noyau, et le log du commit fait référence uniquement à la fiche Jira/Bugzilla/… Et vous n'avez que la version finale du code. L'intégrateur est juste là pour faire le taf d'intégration, il ne comprend pas grand chose au code, et par ailleurs il s'en fout.
Avec un peu de malchance, la branche qui avait servi au développement a été supprimée pour gratter de la place (ou était uniquement sur le poste local du développeur, un presta qui a depuis fini sa mission ; le poste a donc été reformaté).
Du coup, vous avez juste :
- le commit qui dit "merge de la fiche XXX-1234 dans le tronc principal"
- votre bug tracker qui indique le nom de la personne assignée au bug, mais sans certitude que ce soit bien elle qui ait produit le code
- perdu le détail des itérations du code
Et là, vous avez un doute. Ce qui semble être un bug à la lecture du code (mal commenté) est peut-être volontaire. Le dev a peut-être été obligé d'écrire ça pour contourner autre chose. Après tout, ce damné soft est un cauchemart, le résultat de plusieurs années de retouches successives que personne ne maîtrise plus depuis bien longtemps.
Bref…
En gros, la question c'est :
- est-il préférable d'avoir tout le détail du code dans un arbre unique, avec tous les micro-commits, mais au moins on garde tout, pour toujours, et on peut tout retrouver
- ou est-il préférable de n'avoir que les commits "finaux", quitte à perdre le ou les auteurs intermédiaires et les versions intermédiaires en cas de stratégie de stockage merdique/très contrainte
- ou avez-vous d'autres approches ?
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par jihele . Évalué à 6.
Je ne comprends pas trop.
Dans git, quand tu intègre une branche dans ta branche principale, tu as un commit de merge (toujours s'il y a un merge, ou optionnellement si c'est du fast-forward) mais tu récupères aussi dans l'historique les commits de la branche de dev, donc tu as rien perdu et tu peux supprimer la branche de dev car elle ne comporte aucune info supplémentaire.
Concrètement, le commit de merge est juste un commit qui a deux parents : le dernier commit de la branche master et celui de la branche de dev. Donc on peut remonter tous les commits de la branch de dev. Et si on veut pas se trimballer plein de commits temporaires dans master, on peut squasher les commits de la branch de dev avant intégration, mais on aura au moins un commit de dev avec une trace écrite.
Ben non, vous avez le commit de merge et au moins un commit de dev qui indique qui a codé et vous conservez les itérations que vous voulez (squash ou pas).
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par benoar . Évalué à 7. Dernière modification le 19 septembre 2018 à 10:25.
Tu peux faire un entre-deux, comme pour le noyau : le code intégré doit être formaté et séparé comme il faut, en commits ni trop gros ni étant des commit « de travail » (genre du « fix that », « update » ou « work in progress »). Les branches des devs sont retravaillées (rebasée) jusqu'à avoir une tête correcte pour pouvoir être mergée sans avoir les détails de comment le travail a été fait, mais plutôt le détail de la signification d'ensemble cohérents (genre on sépare le cœur d'une feature de son activation dans le reste du code). Toutes cette préparation est effectuée par échange de mails sur la LKML en ce qui concerne Linux.
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8.
Ici on a un gitlab, des merge requests qui conservent l'historique, et des intégrateurs qui font leur travail pour vérifier que le code est bien écrit, commenté et documenté. Sinon, il n'est pas intégré.
Il faut peut-être aller expliquer leur travail à vos intégrateurs.
On a déjà bien assez de dette technique comme ça, on a tout intérêt à ce que au moins le code qu'on écrit soit propre. On est prestataires (grosse équipe, une quarantaine de personnes sur différents projets) et le dépôt git est évidemment synchronisé chez le client toutes les nuits, de façon à ce qu'il aie accès à l'historique (sauf les branches "internes" qui restent chez nous avec les devs en cours pas encore livrés). Si vos prestataires vous envoie le code en vrac par mail et sans contrôle de sources, vous avez là aussi un problème.
On ne développe pas de code sur nos propres machines, mais sur un serveur partagé avec un environnement de travail maîtrisé. Ce qui fait que formater un PC n'est jamais un problème, et aussi qui permet au client de savoir exactement dans quelle configuration on travaille et de reproduire l'environnement chez lui si nécessaire.
Pour les commits, on ne garde pas tout, l'idée est que le développeur fait son développement et prend le temps de découper ça en commits "atomiques" apportant chacun une fonctionnalité précise, et étant fonctionnel et indépendant des commits suivants. Gitlab ni Github ne mettent pas vraiment cette façon de travailler, si j'avais le choix je pencherais plutôt pour un outil comme Gerrit, qui permet de faire une revue de code en travaillant sur un commit à la fois.
Mais de toutes façons, les développements sont découpés en tâches qui peuvent être complétées en quelques jours, au pire une à deux semaines si vraiment ça se passe mal. Les revues et intégrations sont donc très fréquentes et concernent peu de commits à la fois. Les commits de développement sont au nom de l'auteur, le commit d'intégration au nom du relecteur/intégrateur. Tout est donc tracé.
L'historique git est un outil précieux pour comprendre le fonctionnement du code, et s'il est bien tenu, souvent plus efficace que des commentaires ou de la documentation d'architecture.
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par Sufflope (site web personnel) . Évalué à 3. Dernière modification le 19 septembre 2018 à 16:03.
Concernant gitlab, depuis quelques versions, si tu commentes sur un commit, le commentaire est conservé dans la MR même si tu écrases le commit avec un push-force. Ça permet de faire une review commit par commit (l'interface de review permettant de soit voir tout le diff, soit ne voir qu'un commit à la fois). Ça plus la config pour n'autoriser le merge que s'il est fast-forward, que si les discussions sont résolues, et si la CI passe, et t'es pas mal. Même si j'imagine que Gerrit va plus loin (mais peut-être plus complexe et moins souple).
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Oui, c'est pas impossible à faire avec Gitlab mais c'est pénible.
Gerrit permet aussi de merger un commit avant que les suivants ne soient prêts, par exemple.
Ce n'est pas forcément moins souple, c'est juste une façon différente de travailler.
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par raphj . Évalué à 10.
Souvent, avec un oreiller et un bon matelas :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.