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

[David Verdin <adresse@cachée>]

Bonjour et merci de ta réponse,

Le 10/09/12 21:38, Marc Chantreux a écrit :

On Mon, Sep 10, 2012 at 05:40:01PM +0200, David Verdin wrote:

Bonjour,
Le 09/09/12 20:45, Marc Chantreux a écrit :

Bonjour,

* les perl traps qui méritent d'être développées sur le wiki

Pour éviter des attaques vers les listes à partir du wiki ?

je parlais de la section "perl traps" de la page
http://www.sympa.org/dev/contributors/developers_howto

par exemple, l'erreur qui consiste à ne pas comprendre pourquoi 

    @foo = undef

crée un tableau de 1 élément montre le programmeur concerné n'a pas bien
compris le role des listes en perl. Une explication lui permettrait une
meilleure lecture et écriture de code plutot que le souvenir d'une
curiosité syntaxique.

et du coup:

    my $self = shift; 
    my %args = @_;

devient 

    my ( $self, %args ) = @_;

Oui, ça se serait en effet très positif. Donner un exemple de ce qu'il faut faire serait plus didactique pour les lecteurs.
En te connectant avec l'adresse adresse@cachée, tu devrais pouvoir éditer cette page (elle est ouverte aux abonnés de sympa-fr et sympa-users).

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 ?
Plus généralement, tu soulèves un aspect intéressant. Sympa est un projet distribué. Nous avons de nombreuses contributions et il est délicat de forcer les contributeurs à changer leurs pratiques de 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.
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).

* le packaging cpan de certaines parties

S'agit-il de transformer les bibliothèques Sympa en module CPAN ou
bien d'améliorer le packaging CPAN des modules sur lesquels Sympa
s'appuie ?

les deux: j'ai vu des parties qui pourraient etre bien utiles sous la
forme de modules. ma stratégie serait:

* 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. C'est même une des causes les plus fréquentes 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.
Or Guillaume Rousse a fait un gros boulot à l'occasion de la sortie de la 6.0 pour que Sympa soit facile à packager et ça marche très bien : les RPM sont au taquet de la 6.1 et les .deb suivent beaucoup plus vite qu'avant.
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).
Multiplier les nombre de modules CPAN, c'est aussi multiplier les dépendances des paquets et alourdir la création des packages.

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...
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. On ne remplacera donc du code maison par des modules que s'il y a une réelle plus value fonctionnelle.

Cela dit : il est vrai que le ticket d'entrée dans Sympa est pour le moment assez élevé. Le code n'est pas toujours factorisé comme il le faudrait et un certain nombre de fonctions pourraient être regroupées en module. C'est un boulot non seulement utile mais, je pense, vital pour le projet. Guillaume rousse a envisagé d'entreprendre un travail sur une évolution similaire. Vous pourriez peut-être accorder vos montres sur ce sujet. Un travail sur une amélioration de notre design de code par deux experts du perl serait certainement très utile.
En revanche, je t'invite à travailler sur la branche 6.2 de Sympa. En effet, on a fait de gros changements dans Sympa et je suis en train d'intégrer la toute dernière fonctionnalité dans la branche 6.2. Le code aura beaucoup changé et on arrive au bout d'une grosse évolution du produit. Après, ce sera le moment idéal pour se lancer dans des boulots de refactorisation / mise au carré du code. "Après", c'est quand on aura fait passer Sympa 6.2 en beta ce qui devrait être une question de semaines désormais.

* é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.

* des tests unitaires et de coverage

Vaste programme. Ça fait quelques temps qu'on a envie de s'y atteler
mais on n'a pas encore trouvé le temps.

gros chantier en effet et je ne me voyais pas me fixer une date ou un
objectif de couverture: plutot écrire des tests dans les parties que je
touche ou pour les bugs que je ferme.

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

* exposer l'api sympa en REST

Je ne te cache pas que c'est un très gros chantier qui imposera pas
mal de refactorisation de code.

c'est un tres bon moment pour remplacer du legacy par des modules cpan
et écrire des tests unitaires :) 

OK pour les tests unitaires. Pour les modules, voir plus haut.

* plackisation de l'application

Alors là, je cale. Comme je pense que tu ne parles pas
d'installation de cloisons en plâtre, je suppose que je vais pouvoir
apprendre un mot. Qu'est-ce que la "plackisation" d'une application

ok. plack est l'implémentation de PSGI (équivalent de python WSGI ou
ruby rack) propose de nombreux avantages comme par exemple: 

* une abstraction par rapport à la machinerie http utilisée ( CGI, FCGI,
  module apache ou tout simplement des httpd directement écrits comme
  modules perl ou des outils naissants comme mongrel2 utilisant zeroMQ) 
* un systeme de plugin permettant toute sorte de manipulation tant sur
  la requete entrante que sur le contenu renvoyé
* un ecosysteme et une communauté très riche (les developpeurs de
  catalyst, dancer, Web::Simple, Web::Machine, Tatsumaki, … )

J'aurais voulu m'abonner à la liste de développement mais aucun des liens ne fonctionne (dev, sympa-dev, sympa-authors, …) et je me demandais si il existait un dépot git de sympa (il y a bien Sympa/sympa sur github mais c'est un simple export de 3 ans d'age).

ses avantage, ne serait-ce que pour retrouver l'ordre dans lequel
les modifications ont été faites.

parcequ'on ne pourrait pas avec git ?

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, mais il existe peut-être un autre moyen de retrouver l'ordre des commits et des merges.
Plutôt que de parler dans le vide, je vais expliquer les contraintes du projet Sympa.

Lorsqu'on sort une version, on utilise un script qui automatise un grand nombre de choses : récupération et mise à jour des traductions depuis le dépôt pootle, constitution automatique du changelog, tests d'erreurs perl, etc.
On a acquis une suffisamment bonne expertise de subversion pour analyser nos branches de développement, suivre les fusions entre branches et donc se simplifier le boulot. Avant qu'on fasse ce script, sortir une nouvelle version de Sympa nous prenait une demi à une journée, suivant l'ampleur du boulot à réaliser sur les traductions. Maintenant ça nous prend une heure à tout casser. C'est autant de temps de gagné pour faire le "vrai" boulot. Il est important que ce confort persiste, ça nous permet de sortir des versions plus facilement.

Par ailleurs, la base installé de Sympa est très importante et nous savons à quel problèmes s'expose un admin si la mise à jour de son Sympa se passe mal. Les listes, on se rend compte que c'est important quand elle ne fonctionnent plus. Et si c'est le président de l'université qui s'en rend compte, c'est mauvais. Il est donc important que nous maîtrisions les changements qui sont inclus dans le code. Avec subversion, c'est facile à suivre pour nous. Soit on a des développeurs qu'on connaît bien, à qui on  fait confiance, et on leur ouvre les branches de stabilisation. On peut suivre leurs commits au jour le jour (Sourcesup nous envoie des messages à chaque fois qu'un commit a lieu). Par ailleurs, on a pu mettre en place des contrôle de pré-commit pour contrôler ce qui est envoyé : suppression des traces de développement, format du message de commit, etc. On  la main là-dessus. L'autre cas, c'est un projet de développement spécialisé : quelqu'un a un projet de nouvelle fonctionnalité. Il nous écrit, on lui crée une branche, il fait ce qu'il veut dessus et une fois qu'il a terminé, il nous prévient. On vérifie son code et on l'intègre dans le trunk. Pareil, on connaît assez bien subversion pour que ça soit facile à faire.

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,

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.

Je suis prêt à réouvrir le débat: quels intérêts majeurs rendent git
important ?

rapidement: je détaillerais au besoin:

* 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.
pull request, je ne vois pas ce que c'est . C'est spécifique à Git ?

 ca donne envie d'essayer et de voir.
  installer le client svn, se souvenir de son fonctionnement, trouver le
  lien vers le depot subversion et trouver dans la doc qu'il faut
  demander aux developpeurs de créer une branche, ca donne clairement
  moins envie.

Sur Git, tu n'ouvres pas forcément ton dépôt aux quatre vents non plus, je pense. Tu as aussi sans doute besoin d'un client local, sinon comment communiquer avec le dépôt ? Et tu as bien besoin de 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.

* facilite la bidouille dans le sens ou tu fais ce que tu veux sur ton
  dépot, tout en gardant l'historique,

C'est possible aussi avec subversion. Une fois que tu as ta branche, tu y est maître chez toi.

 tu peux facilement remerger les
  branches chez toi, sans passer par le serveur.

L'avantage majeur que je vois à git, c'est effectivement la simplification des fusions pour des gens travaillant sur la même branche de développement. C'est à mon avis l'apport majeur et 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.

 nul besoin d'une
  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 ?

* 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 ?
Justement, à forker des forks de forks, est-ce qu'on conserve une cohérence au projet ? Comment sait-on à quelle branche on peut faire confiance pour installer un Sympa chez soi ? À l'heure actuelle, c'est assez simple : on a une branche instable et une branche stable.

* l'ecosystème git grandit de jour en jour avec une foule d'outils, de
  hooks, de wrappers qui bornent son utilisation à la méthode de
  développement définie par le projet.

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 ?

* ca permetterait facilement de synchroniser un depot sourcesup
 (utilisant l'infra sourcesup pour l'intégration continue par exemple) 
  et github pour donner de la visiblité au projet et utiliser les outils
  de collaboration.

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. Le gros de notre interrogation est de comprendre si on peut passer à git sans trop de casse et avec un réel apport fonctionnel.
Si utiliser git n'est possible correctement que dans github, c'est à mon avis un gros défaut du système.

Je cherche donc des pistes pour commencer à suivre les activités de développement.

Tu les as ! 

cool! salut a tous!

En résumé, on peut :
- intégrer un patch que tu soumets par mail

dans le cas de git: la personne souhaitant intégrer mon patch pourrait
simplement faire un fetch de mon depot puis merger automatiquement (ou
interactivement, en faisant les diff qui lui plaisent) ma branche dans
la sienne. pour les choses simples, ca se fait en général par quelques
clicks directement dans github.

OK.

- te créer ta propre branche de développement si tu as un projet
important de développement

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 ?

- si tu peux t'investir dans Sympa sur le long terme, t'intégrer
dans les "core developpers", c'est-à-dire ceux qui ont un accès
permanent sur les branches de stabilisation de Sympa. 

ce qui reviendrait dans github a m'ajouter dans les collaborators du
depot officiel (simple click aussi) 

Pareil pour Sourcesup. :)

Merci beaucoup de ton intérêt pour Sympa et de ces idées de
développement et à bientôt !

je suis abonné a des universalistes depuis le millénaire dernier, j'ai
utilisé sympa a de nombreuses autres occasions (dans le monde
universitaire) et je suis tjrs un peu triste de voir que les listes de
mongueurs.net sont gérées avec mailman (sans avoir jamais fais de
proposition puisque je ne maitrise pas l'outil). Aussi suis-je heureux
d'être en position de pouvoir offrir à mon tour à sympa.

Et on t'en est très reconnaissant !
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.

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.

Bonne fin de journée,

David

cordialement,
marc

Attachment: smime.p7s
Description: Signature cryptographique S/MIME