Journal Remonter l'historique du noyau avec git depuis le début

Posté par  . Licence CC By‑SA.
Étiquettes :
72
18
sept.
2018

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  . É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  . É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  . É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  . É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  . É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 :

         - La version avec `echo` :
            [code=bash <<<
                echo "toto"
            >>>]
        
         - La version avec `printf` :
            [code=bash <<<
                printf "toto\n"
            >>>]
        

        Ou, si on veut être plus explicite :

         - La version avec `echo` : [
            [code=bash <<<
                echo "toto"
            >>>]
         ]
        
         - La version avec `printf` : [
            [code=bash <<<
                printf "toto\n"
            >>>]
         ]
        

        Pour une citation :

        Voici ce que cette page disait :
        
        [quote
            Ce code ne fonctionne pas toujours comme attendu :
            [code=bash <<<
                echo "$message"
            >>>]
        ]
        

        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 :

        [ = Titre 1
            Cette section présente tartempion, un dessert peu connu.
        
            [ = Titre 1.1
                Lorem ipsum...
            ]
        ]
        

        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  (site web personnel) . Évalué à 3. Dernière modification le 19 septembre 2018 à 15:28.

          cela donnerait :

          • la version avec echo :
          echo "toto"
          • la version avec printf :
          printf "toto\n"

          Pour une citation :

          Voici ce que cette page disait :

          Ce code ne fonctionne pas toujours comme attendu :

                  echo "$message"

          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  . É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 :

            <ul>
            <li>la version avec <em>echo</em> :</li>
            </ul>
            
            <pre><code class="bash"><span class="nb">echo</span> <span class="s2">"toto"</span></code></pre>
            
            <ul>
            <li>la version avec printf :</li>
            </ul>

            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  (site web personnel) . Évalué à 4.

              Y a-t-il moyen d'éviter ça ?

              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  . É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  . É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) :

                      > Voici un code dans une citation :
                      >
                      ```
                      echo "salut"
                      ```
                      Un texte dans la citation après le 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 […]" :

                      texte indentée ?
                  ```J'essaie de sortir du bloc de code. Je n'ai pas écrit les trois guillemets qui débutent cette ligne, ils apparaissent tout seuls. Par contre, j'avais passé une ligne qui a disparu. Si je ne passe pas la ligne, ce comportement n'apparaît pas. Idem si je ne passe qu'une ligne et pas deux avant le "texte indenté ?".
                  
                  
                  
                  
                  Je n'arrive pas à sortir de ce bloc de code.
                  
                  J'espère que j'ai réussi à être compréhensible mais ce n'est pas évident. Je suis tombé sur ce comportement en essayant de citer un code.
                  
                  À plus :-]
                  
                  P.S.: Voici la source de ce commentaire : https://framabin.org/p/?e8c3707081753b1b#evPLh7aVALnU5XG6riKUUV966jDFT8EQhCwptTv3vLU=
                  
                  P.P.S : on a des comportements amusants en insérant des ``` dans ce bloc de code.
                  
                  • [^] # Re: Correction

                    Posté par  (site web personnel) . Évalué à 3.

                    je ne sais pas comment citer correctement un code markdown pour produire un bloc de code

                    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 :

                    • le préfixé par #, ## ou ### selon le niveau souhaité (bon il y a parfois un bug dans la table des matières — si tu démarres au niveau 2 sans niveau 1 au-dessus — pas visible immédiatement vu qu'elle ne s'affiche que lorsque dépassés les 2000 caractères iirc)
                    • l'encadré : toujours avec les # (je trouve ça inutile mais bon)
                    • le souligné : ça je trouve que c'est lourd
                    • bon, ça fait 3 modes :D

                    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  . É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  (site web personnel) . Évalué à 3. Dernière modification le 21 septembre 2018 à 00:15.

                  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

                  ç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  (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?

  • # Tiens, à propos, comment-vous gérez vos repos, vous ?

    Posté par  . É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  . É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.

      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

      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  . Évalué à 7. Dernière modification le 19 septembre 2018 à 10:25.

      • 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

      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  (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  (site web personnel) . Évalué à 3. Dernière modification le 19 septembre 2018 à 16:03.

        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.

        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  . Évalué à 10.

      Comment vous gérez vos repos ?

      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.