Re: [sympa-fr] liste de développement?

[Marc Chantreux <adresse@cachée>]

salut et pardon pour cette réponse tardive, 

la réponse qui suit n'est que le reflet de ma propre experience. je ne
met pas de "je pense" devant chaque phrase mais je ne suis nullement
péremptoire.

On Wed, Sep 12, 2012 at 05:39:00PM +0200, David Verdin wrote:
> >ensuite j'aimerais virer les référence a & dans les appels de fonction:
> >l'appel via & est bien utile puisqu'il transmet @_ (héritage de perl4)
> >mais ca peut conduire à des bugs déroutants quand on ne connait pas le
> >principe ca n'a pas de sens dans les exemples que j'ai vu.
> Quels types de bugs ces appels peuvent provoquer ?

imagine une fonction dont les arguments sont optionnels, tu va trouver
dans le corps de ta fonction qqchose comme: 

sub faire_des_choses {
    @_ ? faire_un_truc(shift @_) : faire_autre_chose
}

soit maintenant la fonction 

sub choses_a_faire {

    faire_des_choses;   # appelle faire_autre_chose
    faire_des_choses(@_);  # appelle faire_un_truc

    # par contre:

    &faire_des_choses; # partage @_ avec faire_des_choses
    # appelle faire_un_truc
    # supprime un element du tableau (parceque)

    # du coup:
    say for @_;

    # oops ? ou est passé le premier argument ?
    # il a été mangé par l'appel faire_un_truc( shift @_ )

}

le 3eme comportement, bien que fort utile dans certains cas,
est piégeux pour la plupart des gens qui ne pratiquent pas perl au
quotidien. J'imagine que si ils ne comprennent pas ce que @a = undef
veut dire, ils sont loin de s'imaginer ce que &faire_des_choses
provoque.

> développement. Par conséquent, le code de Sympa est parfois
> hétérogène : de la formule quasi-ésotérique pondue par un guru perl
> jusqu'au code sans le moindre raccourci permis par le langage.

je crois que la regle ici est simple a fixer: utiliser & uniquement si
on veut que l'appel de fonction aie un effet de bord sur @_.

> Il serait peut-être, cependant, possible de tomber d'accord sur un
> nombre limité de règles communes de développement (comme passer les
> arguments d'une fonction dans un hash, par exemple, pour faciliter
> l'évolution des fonctions).

Il faut lire "Perl Best Practices" de Damian Conway: certaines parties
ont clairement vécu (le modele objet proposé par exemple est clairement
déprécié par des modules comme Moo, plus proche des idiomes de Perl6 et
devenu le standard de Perl5).

> >* chercher sur le cpan si un module ne peut pas remplacer ces fonctions
> Pas sûr que ce soit toujours pertinent. En effet, Sympa s'appuie
> déjà sur un paquet de modules CPAN et ça alourdit considérablement
> l'installation.

J'avoue ne pas comprendre: au contraire, les outils comme cpanm,
Local::lib, dh-make-perl et autres permettent de packager intégralement
des applis dans CPAN et de déployer la base de code stable par une
simple commande.

Ensuite, utiliser CPAN permet de ne pas résoudre des problèmes
solutionnés par d'autre: c'est de la maintenance de code en moins.

> d'ennuis à l'installation. À vrai dire, le plus facile pour
> installer un module CPAN, c'est souvent d'attendre qu'on en ait fait
> un RPM ou un .deb.

outch... je suis d'avis au contraire de ne plus me reposer sur les
paquets du système (souvent trop anciennes) pour faire tourner des
applis non-packagées.

en gros: soit je package entièrement l'application (c'est une
possibilité: il est facile de participer à la liste debian-perl), soit
je laisse cpanm (ou carton ou autre) tout installer dans un repertoire
séparé. Le second cas est bien pratique quand on a sur la même machine
des environements nécessitant des versions différentes des modules.

> C'est une très grosse valeur ajoutée pour le projet parce que bon
> nombre d'admins préfèrent installer des versions packagées de Sympa
> (notamment parce que les modules CPAN sont installés en tant que
> dépendance).

c'est le cas aussi en utilisant le client cpan et sa version lite cpanm.

> Multiplier les nombre de modules CPAN, c'est aussi multiplier les
> dépendances des paquets et alourdir la création des packages.

pour debian, un dh-make-perl et un dpkg-scanpackage m'a permis de faire
des depots rapidement et je pense qu'on pourrait rapidement contribuer a
debian si besoin.

pour les RPMs: j'avais trouvé les outils tellement mauvais (sous RH et
suse) que j'utilise perlbrew et local::lib pour faire des environnements
indépendant (perlbrew recompile un interpreteur: au moins c'est a jour
et pas buggé).

la situation a pe évolué de ce coté-ci: je n'ai pas suivi l'évolution.

> Deuxième point : on a déjà eu des gros problèmes avec des modules
> CPAN qui décident à la place des développeurs ce qu'un programme
> doit faire ou non. Par exemple, appeler la méthode croak quand il y
> a une erreur...

certes: dans ce cas la il faut créer un autre module et expliquer la
différence avec l'existant dans une partie visible de la doc.

> Par ailleurs, les modules que nous avons développés pour Sympa font
> ce que nous voulons. On connaît le code, on le maîtrise et on
> l'adapte comme on veut. J'ai récemment passé plusieurs jours à
> comprendre pourquoi Sympa partait parfois en vrille lors de
> signatures DKIM sur certains messages parce qu'on utilise un module
> particulièrement hermétique du point de vue du code.

La encore: enrichir CPAN plutot que sympa me parrait utile. Une
discution s'est elle engagée entre le mainteneur et les developpeurs
sympa? une bonne idée peut pe germer? 


J'ai contribué a koha qui paye actuellement très cher (en terme de
maintenance) le fait de ne pas s'etre appuyé sur CPAN.

> remplacera donc du code maison par des modules que s'il y a une
> réelle plus value fonctionnelle.

OK
 
> >* écrire ces modules si manquant et deporter le code de sympa dans ces
> >   modules.
> Pareil, c'est risqué; c'est séduisant sur le papier, mais encore
> faut-il avoir le temps de maintenir ces modules. Et de trouver des
> mainteneurs pour les RPM, .deb, etc.

bah si y'a que ca et que Guillaume veut bien se charger des rpms: je
suis contributeur CPAN et le maintient de depots debian/ubuntu ne me
fait pas peur (meme proposer la maintenance de ces paquets via
debian-perl).

> Ça semble sage, en effet. ;)
> Connais-tu un bon framework de tests unitaires pour Perl ?

j'ai tendance a utiliser prove pour le moment (la commande de test
fourni avec la distrib) avec les éméteurs TAP et HTML. Nous commençons
un projet jenkins/sonar à l'université et sympa pourrait pe bénéficier
de cette infra.

> Je n'en suis pas sûr. J'ai eu un doute sur le sujet quand j'ai
> appris que les commits de git étaient identifiés par des hash et non
> des numéros

hash qui je crois depend du hash précédent. en tout cas je connais 2
facons de merger les branches:

* git merge permet de garder les commits dans le bon ordre
* git rebase permet de placer les patches de la branche a merger au
  sommet de l'historique
* tu peux te rendre compte rapidement de cet historique en utilisant la
  commande git log ou une interface graphique comme gittk.

> Les éléments à maintenir absolument pour nous sont donc les suivants :
> 
>  * Contrôler le code intégré dans le projet,
>  * Être capable, automatiquement, de reconstituer la liste exacte des
>    modifications apportées à une branche et s'en servir pour créer un
>    NEWS file,
>  * Disposer de hooks de pre-commits pour pouvoir refuser un commit ne
>    respectant pas un nombre minimum de règles,

il me semble que les projets git font des choses analogues assez
simplement (les git-hooks par exemple décrivent les actions automatiques
a plusieurs étapes de l'intégration d'un commit sur le serveur,
pre-commit faisant partie du lot). c'est git diff qui s'occupe des
différences entre branches et même entre 2 commits arbitraires.

maintenant: je ne me rend pe pas compte de la complexité de ce que vous
faites. a discuter plus avant donc: en attendant: j'utiliserais le
module svn de git, je pense.

> Voilà, ça c'est nojs besoins. Parlons de ceux des contributeurs.
> C'est nous qui avons besoin de vous et pas l'inverse, donc il faut
> qu'on s'entende.

les changements que je proposais sont dictées par ma propre experience:
l'utilisation massive de CPAN et de git sont mon quotidien et je peine à
l'idéee de devoir faire machine arrière. pour parler un peu plus de git:
de gros projets (comme linux, perl, postgresql, QT, gnome, eclipse, ...)
sont maintenant sous git. Linus donne lui-même son avis sur svn dans
cette video. Je ne prend pas ce que dis Linus pour argent content mais
ses propos sont intéressants:

http://www.youtube.com/watch?v=4XpnKHJAok8

> >* facilite l'acces a la contribution (surtout si le projet est hebergé
> >   par github): les operations les plus courantes (fork, pull request,
> >   merge, ...) se font en qq clicks.
> C'est surtout le fork qui est important, non ? Sur Sympa, ce sont
> les gestionnaires du projet qui acceptent ou non l'intégration de
> nouveau code.

pour un gestionnaire de projet, il est facile d'ajouter 2 depots
distants, de merger une branche du depot du contributeur dans sa branche
de travail locale puis de tout pusher sur le serveur de référence

> Sur Git, tu n'ouvres pas forcément ton dépôt aux quatre vents non
> plus, je pense.

il n'est nul besoin: ca n'est pas sur ton depot que le travail
s'effectue: le contributeur clone le depot sur son depot local et
synchronise régulièrement.

> Tu as aussi sans doute besoin d'un client local,

certes. mais je ne connais plus que 2 projets qui me touchent de pret et
qui utilisent encore svn: le votre et le systeme de gestion de
conférences des mongueurs.

> l'URL du dépôt pour te synchroniser. Par ailleurs, un bon nombre
> d'IDE intègrent des fonctions de communication avec un dépôt
> subversion.

c'etait un argument pour svn a l'université de strasbourg mais tout le
monde a vite installé les modules similaires pour git.
 
> C'est possible aussi avec subversion. Une fois que tu as ta branche,
> tu y est maître chez toi.

faut-il que la branche soit créée, ce qui vous demaande du travail. et
si je n'ai pas le temps de contribuer, ce travail sera inutile. 

de plus: je crée une branche par feature ou par bugfix: ca me permet
facilement de savoir ce que j'ai fais pour quel travail et de maintenir
une branche "devel" correspondant a "tout ce qui a deja été fixé ou
ajouté depuis la stable", qui a bossé en meme temps sur quoi et dans
quel ordre les features ont été ajoutées à devel (l'équivalent de
trunk), elle est donc "relativement stable".

> l'argument essentiel d'un switch vers cet outil. Si ça facilite les
> contributions, c'est une bonne raison pour s'y intéresser, à partir
> du moment où on arrive à maintenir les conditions que j'ai énoncées
> précédemment.

je crois que c'est un argument de poids en effet, surtout pour un projet
qui peine à trouver de nouveaux contributeurs: la visibilité est un plus
qu'offre github.

> >   intervention des gens du projet pour permettre a plusieurs personnes
> >   de faire des modifs et de les publier entre eux. (tout ca tjrs en qq
> >   clicks).
> C'est ça qui m'échappe, je pense. Comment les gens font-ils pour
> publier des modifs entre eux ?

ils mergent les depots entre eux: git ne repose pas sur un serveur: les
commandes git permettent de cloner et chercher les mises a jour via ssh
par exemple.

> >* du coup les gens forkent des forks, créent facilement des groupes de
> >   travail, se montrent leurs avancements, leurs pocs, ...
> Qu'est-ce qu'un pocs ?

Proof of concept, pardon. c'est une tentative qui permet de montrer des
choses experimentales ou restant a prouver à la communauté.

> Justement, à forker des forks de forks, est-ce qu'on conserve une
> cohérence au projet? 

dans les faits: 

* les gros contributeurs pushent souvent 
* les autres font des modifications mineures et en général facilement
  intégrables 

je ne suis jamais tombé sur le cas d'une branche qui vit sa vie pendant
1 an pour finalement proposer des killer features.

> Comment sait-on à quelle branche on peut faire
> confiance pour installer un Sympa chez soi ?

les developpeurs se font confiance entre eux, les autres utilisent la
branche master du depot de référence (celui de sourcesup par exemple).

> À l'heure actuelle,
> c'est assez simple : on a une branche instable et une branche
> stable.

je te propose de suivre ce lien:

http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

le grand classique dans les depots c'est:

* une branche stable (master) sur laquelle on tag la derniere version de
  distribution (genre 6.0)
* une branche devel  (devel) qui correspondrait pe a 6.2 
* une branche par bugfix ou feature en cours de développement 

à l'usage:

* quand la feature est finie, elle est intégrée a devel
* quand devel est stable (testé, validé fonctionnellement, que plus
  personne ne reporte de bug et que toutes les fonctionnalités attendues
  sont là), on merge dans master et on tag (6.2)

> Ah ben tiens, tu réponds je pense à certaines de mes interrogations.
> On a donc bien des hooks avec git. Bien. C'est avec git en général
> ou juste github ?

c'est dans git directement.

mkdir /tmp/foo
cd /tmp/foo
git init # je commence un nouveau projet
find .git/hooks -type f

.git/hooks/post-update.sample
.git/hooks/applypatch-msg.sample
.git/hooks/commit-msg.sample
.git/hooks/prepare-commit-msg.sample
.git/hooks/pre-commit.sample
.git/hooks/pre-applypatch.sample
.git/hooks/pre-rebase.sample
.git/hooks/update.sample
.git/hooks/post-commit.sample
.git/hooks/post-receive.sample

tu as juste a mv pre-commit.sample par sample et modifier son contenu
pour adopter le comportement désiré. coté serveur: c'est la meme.

ce sont les hooks qui permettent par exemple de pusher les events du
depot vers les outils d'intégration continue, de refuser un push si une
erreur est détéctée.

> Il n'est pas question pour nous de quitter Sourcesup. C'est une
> forge qui nous donne entière satisfaction et qui par ailleurs
> fournit des dépôts git.

biensur! mais il sera tres facile pour moi de créer un depot synchronisé
dispo sur github et de garder mes habitudes sans perturber les votres.

> Si utiliser git n'est possible correctement que dans github, c'est à
> mon avis un gros défaut du système.

non: github n'est qu'un réseau social créé pour mettre les développeurs
en relation plus facilement, on suit ses developpeurs préférés pour voir
ce qu'ils font, qui ils suivent, on découvre des projets sympas.

git existait donc avant github et nombre ont fait le choix (parfois
simplement parceque github est une infrastructure gratuite mais pas
libre) de ne pas utiliser github.

on peut tranquillement rester sur sourcesup ou meme se passer
completement d'une infra pour vue qu'un ssh soit dispo qqpart.

> >nul besoin avec github: je peux maintenir ma branche dans mon coin et
> >venir vous voir quand j'ai vraiment qqchose a montrer. plus simple pour
> >moi, plus léger pour vous.
> Ça c'est cool. Mais on peut le faire sans github ou pas ?

toutes les fonctionnalités que j'ai proposé sont dispos dans git et il
n'y a meme pas besoin de serveur. tu veux commencer un nouveau projet?
tu crées un nouveau répertoire et tu tappes "git init".

tu veux cloner un projet existant sur la machine de jean-luc? 

git clone -o jl ssh://adresse@cachée
git checkout jl/devel

tu veux resynchroniser pour voir ses evolutions sans casser ton travail
en cours (les branches distantes n'affectent pas tes branches locale)

git fetch
git diff jl/devel

tu aimes ce qu'il a fait ?

git merge jl/devel

tu veux pusher ta nouvelle version chez lui? 

git commit
git push 

la grande différence au debut avec git c'est que tu dis quels sont les
fichiers concernées par les commits avec git add.

imagine que tu as modifié les fichiers back.c et back.pl. le fichier
back.c est fini et tu veux le montrer à jl mais c'est encore le brin
dans back.pl.

au lieu de faire un classique 

git add -A # toutes les modifs passent dans le prochain commit 
git commit # je commite localement en ajoutant un beau  commentaire
git push   # j'envoie les modifs chez jl 

tu fais 

git add back.c # seul back.c sera concerné par le prochain commit, tu
peux faire autant de add que tu veux

> >ce qui reviendrait dans github a m'ajouter dans les collaborators du
> >depot officiel (simple click aussi)
> Pareil pour Sourcesup. :)

:) 

cool! comme dit: ce qui m'importe c'est git, pas github.

> Comme tu l'as vu, travailler sur Sympa impose quelques contraintes,
> mais rien d'horrible à notre sens. Si certaines des remarques que
> j'ai faites dans ce message te semblent scandaleuse, n'hésite pas à
> nous expliquer pourquoi. On peut se tromper aussi, comme tout le
> monde.

rien ne me semble scandaleux, j'espere de mon coté n'avoir brusqué
personne: ca n'est nullement mon intention.

je vous propose de fairs des tests pour le passage a git si ca vous
branche.

> Enfin, et pour finir le plus long mail de l'année, je vais porter la
> discussion à propos de git sur la liste
> adresse@cachée (après ta réponse sur cette liste si
> tu en as le loisir). C'est plein de contributeurs là-dessus, et il
> est temps qu'on se décide à trancher.

je suis abonné à cette liste et participerais aux discutions cas
échéant.

Bonne nuit à tous 
marc