Valery Fremaux

"Moodle t'envoie plein de messages d'erreur, c'est normal."

Et bien non justement

Ce qui est normal, c'est que Moodle remonte des erreurs de configuration, ou des erreurs de logique d'usage.

Une erreur de codage ou de construction de requête (donc de programmation) est une erreur qu'il ne faut pas signaler mais ABSOLUMENT CORRIGER de toutes façons. Elle ne peut impacter l'utilisateur final pour aucune raison valable. Donc tenter de les masquer par un pseudo message applicatif est idiot, je le maintiens .

 Pour les fonctions deprecated, Moodle n'a en effet pas trop le choix. La fonction reste en usage mais son usage ne constitue pas une "faute" en soi. La détection du deprecated ne vient probablement QUE de l'origine de la fonction, et pas d'une meta-documentation de portage. Moodle dans ce cas fait ce qu'il peut. Je suis d'accord, je me demande encore e matin cmment je remplace isguest() ... (ça va pas durer).

Pour le reste des messags d'erreur, applicatifs par nature, c'est plus propre en effet de signaler à l'usager final dans son langage plutôt que dans le langage natif des développeurs (l'anglais), comme l'ancienne fonction error() laissait le faire. C'est plus de travail à traduire les chaines, mais cela relève la qualité ressentie de Moodle. (j'ai eu une vieille réflexion à ce sujet au Ministère)

Cheers

"Non beatus sed positivus"

Allez une petite dernière, la plus jolie. 

C'est en fait la même que la première, mais l'erreur qui est faite dans la nouvelle syntaxe de $DB->get_records_sql t les nouveaux implciites de codage font que la requête "compile pas".

Résultat : un éran superbement blanc comme neige avec le seul message que voilà.

Là encore : prie et démerde-toi !!!

Il n'y a pas à dire. Tout ce que je découvre me confirme un doute croissant : les HQ ne VEULENT PLUS de développeurs dilétantes. (A noter que : le choix de Git qui est d'un obscurantisme Geek qu'on ne peut plus, et qui fonctionne bien mal sous Windows, et les nouveaux choix architecturaux confirment : 

Vous aviez du mal à suivre en Moodle 1.9 ? alors oubliez Moodle 2, à moins de passer 3 ans de formation en Génie Logiciel dans une école d'Ingénieur !!! )

Aller voir dans cette discussion

Pour notre Daniel qui a demandé de manière si enthousiaste ce portage vers Moodle 2.

Le use_stats est à l'identique.

C'est une première Version Beta que je vous demande d'évaluer avant de la pousser dans le CVS Moodle 2 (ou la faire pousser dans le Git par un moodleur dévoué)

Valery.

Je suis désolé de faire tâche dans ce remarquable consensus.

Je "hais" Git, en matière d'intégrateur qui n'a pas que ça à faire de passer mes journées dans les commits et les branches.

Pour de la production et pour assurer la maîtrise des distributions de nombreuses plates-frmes en versions multiples, Git ne convient pas du tout, à moins de ne vraiment pas avoir d'impératif de délai et de temps (et c'est pas faute d'avoir essayé et travaillé avec pendant 1 an).

Pour les core-developeurs oui en effet c'est un bon outil qui permet plein de manoeuvres complexes et aussi de retracer qui à modifié quoi, de pouvoir récupérer les idées des uns et des autres et de remouliner tout ça.

Les utilisateurs de Git pour synchroniser Moodle standard en prodution ne voient pas le problème de la gestion de la modularité, car ils ne font qu'une synchro globale de Moodle. Mais dès qu'on passe à une gestion modulaire, et gérer des versions multiples de composants, Git est bien moins clair (mais toujours aussi puissant). Les outils un peu habillés ne proposent rien de sérieux en matière de gestion de la modularité. Le principe global n'étant plus la photographie à un instant donné de l'état d'un composant, mals le stockage de toutes les modifications produites entre deux dates de développement. La gestion de la modularité (c'est à dire êtr capable de ne faire évoluer qu'un seul composant) suppose une discipline drastique des développeurs à ne faire qu'un lot de commits de ce composant, ce qui ralourdit largement la gestion des publications et la rend peu aglle). C'est donc à la portée d'une équipe de core-développeurs qui peuvent repousser les deadlines comme ils veulent (c'est pas prêt), mais pas pour les intégrateurs qui doivent livrer "à date".

En production sur des serveur relativement modestes chez des hébergeurs, c'est une abbération de charger les 1.5 Go de versions enterrées de tous les fichiers  Moodle dans le répertoire .git. Une abbération de moins en moins critique en effet avec la chute des coûts d'hébergement.

Je ne sais pas dans quelle mesure le CVS de Moodle reste synchronisé sur la branche principale de version de Git.