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

[Marc Chantreux <adresse@cachée>]

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 ) = @_;

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.

> >* 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
* écrire ces modules si manquant et deporter le code de sympa dans ces
  modules.

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

> >* 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 :) 

> >* 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 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. 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.
* facilite la bidouille dans le sens ou tu fais ce que tu veux sur ton
  dépot, tout en gardant l'historique, tu peux facilement remerger les
  branches chez toi, sans passer par le serveur. 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).
* du coup les gens forkent des forks, créent facilement des groupes de
  travail, se montrent leurs avancements, leurs pocs, ...
* 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.
* 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.

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

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

> - 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) 

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

cordialement,
marc