En effet, il faudrait que nous ajoutions l'accord pour utiliser le captcha de google pour s'enregistrer. J'ai rajouté une entrée dans notre système de suivi sur le sujet: https://tuleap.net/plugins/tracker/?aid=11592
Merci pour les encouragements, ça fait toujours plaisir !
Pour l'interface git, celle ci va être complètement refondue très prochainement (courant de l'été normalement). Je ne crois pas que l'on ait identifié un point spécifique sur les commits signés mais c'est un bon point, je le garde sous le coude.
À ma connaissance le captcha de Google n'est pas incompatible avec RGPD mais je peux me tromper. As tu un pointeur sur le sujet ?
On a mis un captcha parce que tout service ouvert sur le net se fait pourrir par des dizaines de bots tous les jours et que celui de Google est très efficace. As tu des suggestions d'alternatives à soumettre ?
Si la quasi totalité du backend est en PHP pour la partie applicative, nous nous intégrons avec bcp d'autres éléments du système : git, subversion, CVS (omg) mais aussi mailman, vsftp, etc. De plus, certaines fonctions historiques permettent une interaction fine avec le système (genre avoir un compte unix associé à son compte utilisateur).
J'ajouterai que le code d'origine vient d'un temps où l'écosystème PHP était plutôt pauvre en terme de maturité logicielle et que donc nous étions obligé de packager à la mano chaque dépendance de chacune des libs utilisées (à la bonne version, of course).
Avec l'utilisation de composer et la désactivation par défaut des fonctionnalités système trop bas niveau on pourrait faire un portage. Y a plus qu'à trouver quelqu'un de motivé pour le faire.
Concernant l'upgrade des versions de PHP, nous avons basculé à PHP 5.6 sur le tard (courant d'année dernière) et le portage vers PHP 7 avance bon train (le code de Tuleap ayant encore des morceaux "préhistoriques" qui refusent de mourir, ce genre d'upgrade du langage est particulièrement tendue). On devrait avoir un premier round dispo pendant l'été (notre objectif est d'avoir migré avant décembre justement).
Concernant la dépendance à RHEL/CentOS par contre, pas d'avancées. Il s'agit toujours d'un choix de l'équipe de maintenance de se concentrer sur un seul OS. Notre arbitrage à l'heure actuelle est de privilégier les fonctionnalités ou correctif vs. le support d'OS variés (c'est déjà très prenant de maintenir 2 version du même OS).
Quel est le plan de Enalean pour ne pas tomber dans les travers qu'à connu SourceForge à son époque en franchissant trop souvent la ligne jaune ?
Ne pas accepter plus de projets que ce qu'on est capable d'assumer financièrement.
Autrement dit : comment Enalean va financer l'hébergement massif de projets gratuits ?
Nous dédions un budget à ce fonctionnement. Lorsque la limite est atteinte, soit on peut remettre au pot (condition: qu'Enalean ait eu de nouveaux clients afin que les recettes équilibrent les dépenses) soit on se limite aux projets déjà présents (on fera peut être la chasse aux projets morts pour libérer quelques places).
Contrairement à github ou certaines autres plateformes, nous ne vivons pas sur un tas de $$$ prêtés par des VCs (et qui voudront le récupérer), du coup on ne peut pas promettre la lune à tout le monde (c'est d'ailleurs pour cela que nous ne l'avons pas fait plus tôt).
Dommage que l'installation n'ait pas été couronnée de succès.
La version docker est en effet, pour le moment limité à des fins de tests et de démo.
La version "pour la prod" se base uniquement sur du CentOs. Jusqu'a très récemment ce n'était possible que sur du centos/rhel 6 mais les packages centos/rhel 7 arrivent en beta: https://docs.tuleap.org/installation-guide/install-el7.html
Tout à fait, la couverture fonctionnelle est plus large que du github. Nous avons une approche plus horizontale du produit et avec un focus très important sur les éléments de suivi et de gestion de projet (en particulier Agile). Mais la gestion des sources n'est pas en reste, il va y avoir un travail important sur l'interface et le support de git lfs dans les prochaines semaines.
Je n’ai pas trouvé comment explorer les dépôts libre/public sans créer de compte.
L'ouverture a été un peu précipité, du coup tout n'est pas encore bien taillé pour une plateforme publique & anonyme (notre cible habituelle est plutôt encline a tout fermer et barricader…). Bref, la liste est ici: https://tuleap.net/softwaremap/
La force de github, gitlab c’est la facilité de collaborer en ayant malgré tout chacun son espace.
Le pattern de navigation est différent avec Tuleap, c'est certain mais rien n'empêche de collaborer, au contraire. Cependant, la philosophie est que cette collaboration se fait dans le périmètre de un ou plusieurs projets (espaces de travail).
Par exemple il est possible de faire un fork d'un dépôt git, mais ce fork "personnel" restera dans l'espace projet (dans un espace de nom dédié).
Comme mentionné avant, contrairement à github (qui a commencé avec une platforme ouvert pour aller vers un produit entreprise plus fermé) Tuleap a été développé dans un schéma "pour l'entreprise" et va vers un modèle plus ouvert. Des évolutions seront sans doute nécessaire pour s'adapter à se nouveau mode de fonctionnement.
(les idées & contrib sont évidemment les bienvenues)
On s'est toujours tâtés sur le fait d'ouvrir ou pas une platforme à destination des autres projets libres (autres que les projets Tuleap). Le ramdam autour de github a été le coup de pied au c** pour se dire "cette fois on le fait" et ensuite, on verra bien !
Qu'est-ce qui retient le logiciel auprès de CentOS 6, exactement ? Pourquoi un couplage aussi fort ?
Quid de Fedora récents ?
Le couplage est historique (comme souvent) et viens, en particulier d'une série de features "merveilleuses" qui nécessitait d'offrir un accès shell aux utilisateurs (CVS entre autre, on a encore des clients pour ça). Les dépendances qui sont derrière soient, n'existent pas sur CentOs 7 soient n'ont été portés que récemment.
Jusqu'à présent nous attendions d'avoir la stack complète pour faire la migration mais, las d'attendre, nous avons décidé d'attaquer le chantier en désactivant les briques dont les dépendances n'étaient pas présentes. D'où le support centos 7 tardif (c'est dispo en beta actuellement).
Par contre l'OS target reste CentOs (pas même fedora) pour des raisons de simplicité. Une seule famille d'OS à supporter veux dire plus temps à faire de la feature et moins de temps à corriger des problèmes obscures de dépendances incompatibles dans un edge case chelou sur un OS à peine connu.
Pour décentraliser tout, il y a fossil mais ce n'est pas sur une base git.
Pour Git et la revue de code en elle même, il y a un travail de fond en cours de finalisation par les gens de Gerrit afin de stocker toutes les données de revue de code (gestion des comptes & co) dans git, ça s'appelle NoteDB.
Le portage vers Centos7 est en cours, tout ce qui dépend des trackers (issues, agilité, etc) et de git devrait fonctionner mais globalement c'est en beta.
On a pas encore mis à jour le guide d'installation mais si vous voulez tester et rapporter les bugs, on donne les pointeurs sur chat ou la ML. Par contre, c'est fortement déconseillé en prod.
Grosso modo, pour l'instant il s'agit d'avoir un outil de gestion des campagnes de tests (manuels pour le moment). L'étape suivante sera de mettre en cohérence avec les exigences/stories pour offrir la traçabilité.
Ca consomme un json craché par restler mais il n'y a pas de raison de ne pas pouvoir générer ça avec du java (à part peut-être la quantité de mémoire que ça va consommer)
La visualisation gantt est possible au dessus d'un tracker. Exemple bidon, nos sprints
Par contre avec les vraies données (start date, end date, completion & co) ça rend mieux. On l'utilise notamment pour visualiser nos congés (dans un tracker Tuleap, of course ;)).
Mais il n'est pas nécessairement dédié à cela (ie. s'il y a déjà un serveur gerrit qui tourne, avec de la réplication et tout, Tuleap s'integre nativement et sans modifs).
D'ailleurs, on peut aussi avoir plusieurs serveurs Gerrit connectés en simultané (question de charge, de confidentialité, etc).
C'est impossible d'écrire de la merde en Lisp puisque c'est fonctionnel.
En plus c'est plus dur à apprendre que Java donc ça s'adresse uniquement à une élite de développeurs/mathématiciens.
Vu que ça écreme les praticiens, le résultat n'est que meilleur (comme l'ENA, l'X ou epita).
Enfin, la refactorisation de code est juste une hérésie en dynamiquement typé.
Puis
quoi que TDD, tout ça tout ça, mais je vous laisse imaginer le calvaire en Python ou Ruby…
Ça m'a tout l'air d'un gros troll velu mais j'y vais quand même.
Un code conçu en TDD est refactorisable les doigts dans le nez, quelque soit le type de typage (ah ah) utilisé.
Et si ton langage de prédilection est java pour faire du test unitaire ou du TDD, je t'encourage vivement à regarder RSpec pour voir ce qu'un framework de test des années 2010 ressemble (et pourtant je ne suis pas un ruby-iste).
Au boulot on a Bouygues tel et une box qui déconne (pléonasme).
Lors d'une énième plainte au service client, je me suis vu reproché de connecter trop d’appareils à la box car il y avait plus de 5 éléments en réseau sur mon LAN. Comme ce sont les machines des personnes qui travaillent dans la boite, on ne peut pas les débrancher, du coup je demande ce que Bouygues propose.
L'opérateur me répond qu'il faut débrancher des machines (on tourne en rond). Je propose alors de licencier 3 personnes pour qu'Internet fonctionne, l'opérateur m'a répondu "oui voilà c'est ça". Je l'ai fait répéter et il a confirmé.
[^] # Re: Complicité de collecte de données personnelles pour Google ?
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 0.
En effet, il faudrait que nous ajoutions l'accord pour utiliser le captcha de google pour s'enregistrer. J'ai rajouté une entrée dans notre système de suivi sur le sujet: https://tuleap.net/plugins/tracker/?aid=11592
[^] # Re: Gestion de la signature des commits git ?
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 3.
Bonjour,
Merci pour les encouragements, ça fait toujours plaisir !
Pour l'interface git, celle ci va être complètement refondue très prochainement (courant de l'été normalement). Je ne crois pas que l'on ait identifié un point spécifique sur les commits signés mais c'est un bon point, je le garde sous le coude.
[^] # Re: Complicité de collecte de données personnelles pour Google ?
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 1.
À ma connaissance le captcha de Google n'est pas incompatible avec RGPD mais je peux me tromper. As tu un pointeur sur le sujet ?
On a mis un captcha parce que tout service ouvert sur le net se fait pourrir par des dizaines de bots tous les jours et que celui de Google est très efficace. As tu des suggestions d'alternatives à soumettre ?
[^] # Re: intégration de Hg
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 3.
Bonjour,
Pas d'intégration de Mercurial prévu à court terme. Pas qu'on ait quoi que ce soit contre mais pas de contrib ni de financement.
[^] # Re: Installation compliquée et peu paramétrable
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 4.
Si la quasi totalité du backend est en PHP pour la partie applicative, nous nous intégrons avec bcp d'autres éléments du système : git, subversion, CVS (omg) mais aussi mailman, vsftp, etc. De plus, certaines fonctions historiques permettent une interaction fine avec le système (genre avoir un compte unix associé à son compte utilisateur).
J'ajouterai que le code d'origine vient d'un temps où l'écosystème PHP était plutôt pauvre en terme de maturité logicielle et que donc nous étions obligé de packager à la mano chaque dépendance de chacune des libs utilisées (à la bonne version, of course).
Avec l'utilisation de composer et la désactivation par défaut des fonctionnalités système trop bas niveau on pourrait faire un portage. Y a plus qu'à trouver quelqu'un de motivé pour le faire.
[^] # Re: Installation compliquée et peu paramétrable
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 4.
Concernant l'upgrade des versions de PHP, nous avons basculé à PHP 5.6 sur le tard (courant d'année dernière) et le portage vers PHP 7 avance bon train (le code de Tuleap ayant encore des morceaux "préhistoriques" qui refusent de mourir, ce genre d'upgrade du langage est particulièrement tendue). On devrait avoir un premier round dispo pendant l'été (notre objectif est d'avoir migré avant décembre justement).
Concernant la dépendance à RHEL/CentOS par contre, pas d'avancées. Il s'agit toujours d'un choix de l'équipe de maintenance de se concentrer sur un seul OS. Notre arbitrage à l'heure actuelle est de privilégier les fonctionnalités ou correctif vs. le support d'OS variés (c'est déjà très prenant de maintenir 2 version du même OS).
[^] # Re: Quel courage :
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 10.
Ne pas accepter plus de projets que ce qu'on est capable d'assumer financièrement.
Nous dédions un budget à ce fonctionnement. Lorsque la limite est atteinte, soit on peut remettre au pot (condition: qu'Enalean ait eu de nouveaux clients afin que les recettes équilibrent les dépenses) soit on se limite aux projets déjà présents (on fera peut être la chasse aux projets morts pour libérer quelques places).
Contrairement à github ou certaines autres plateformes, nous ne vivons pas sur un tas de $$$ prêtés par des VCs (et qui voudront le récupérer), du coup on ne peut pas promettre la lune à tout le monde (c'est d'ailleurs pour cela que nous ne l'avons pas fait plus tôt).
[^] # Re: Installation compliquée et peu paramétrable
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 1.
Dommage que l'installation n'ait pas été couronnée de succès.
La version docker est en effet, pour le moment limité à des fins de tests et de démo.
La version "pour la prod" se base uniquement sur du CentOs. Jusqu'a très récemment ce n'était possible que sur du centos/rhel 6 mais les packages centos/rhel 7 arrivent en beta: https://docs.tuleap.org/installation-guide/install-el7.html
[^] # Re: Concurent de Jira+bitbucket ?
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 5.
Merci.
Tout à fait, la couverture fonctionnelle est plus large que du github. Nous avons une approche plus horizontale du produit et avec un focus très important sur les éléments de suivi et de gestion de projet (en particulier Agile). Mais la gestion des sources n'est pas en reste, il va y avoir un travail important sur l'interface et le support de git lfs dans les prochaines semaines.
[^] # Re: Super Nouvelle
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 10.
L'ouverture a été un peu précipité, du coup tout n'est pas encore bien taillé pour une plateforme publique & anonyme (notre cible habituelle est plutôt encline a tout fermer et barricader…). Bref, la liste est ici: https://tuleap.net/softwaremap/
Le pattern de navigation est différent avec Tuleap, c'est certain mais rien n'empêche de collaborer, au contraire. Cependant, la philosophie est que cette collaboration se fait dans le périmètre de un ou plusieurs projets (espaces de travail).
Par exemple il est possible de faire un fork d'un dépôt git, mais ce fork "personnel" restera dans l'espace projet (dans un espace de nom dédié).
Comme mentionné avant, contrairement à github (qui a commencé avec une platforme ouvert pour aller vers un produit entreprise plus fermé) Tuleap a été développé dans un schéma "pour l'entreprise" et va vers un modèle plus ouvert. Des évolutions seront sans doute nécessaire pour s'adapter à se nouveau mode de fonctionnement.
(les idées & contrib sont évidemment les bienvenues)
[^] # Re: Bravo !
Posté par vaceletm (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 10.
Merci !
On s'est toujours tâtés sur le fait d'ouvrir ou pas une platforme à destination des autres projets libres (autres que les projets Tuleap). Le ramdam autour de github a été le coup de pied au c** pour se dire "cette fois on le fait" et ensuite, on verra bien !
[^] # Re: Pile logicielle et dépendance
Posté par vaceletm (site web personnel) . En réponse à la dépêche Scrum, Kanban, Git Pull Request, Tests : tout‐en‐un dans Tuleap 10. Évalué à 3.
Le couplage est historique (comme souvent) et viens, en particulier d'une série de features "merveilleuses" qui nécessitait d'offrir un accès shell aux utilisateurs (CVS entre autre, on a encore des clients pour ça). Les dépendances qui sont derrière soient, n'existent pas sur CentOs 7 soient n'ont été portés que récemment.
Jusqu'à présent nous attendions d'avoir la stack complète pour faire la migration mais, las d'attendre, nous avons décidé d'attaquer le chantier en désactivant les briques dont les dépendances n'étaient pas présentes. D'où le support centos 7 tardif (c'est dispo en beta actuellement).
Par contre l'OS target reste CentOs (pas même fedora) pour des raisons de simplicité. Une seule famille d'OS à supporter veux dire plus temps à faire de la feature et moins de temps à corriger des problèmes obscures de dépendances incompatibles dans un edge case chelou sur un OS à peine connu.
[^] # Re: et en decentralise ?
Posté par vaceletm (site web personnel) . En réponse à la dépêche Scrum, Kanban, Git Pull Request, Tests : tout‐en‐un dans Tuleap 10. Évalué à 3.
Pour décentraliser tout, il y a fossil mais ce n'est pas sur une base git.
Pour Git et la revue de code en elle même, il y a un travail de fond en cours de finalisation par les gens de Gerrit afin de stocker toutes les données de revue de code (gestion des comptes & co) dans git, ça s'appelle NoteDB.
[^] # Re: Points de vue?
Posté par vaceletm (site web personnel) . En réponse à la dépêche Scrum, Kanban, Git Pull Request, Tests : tout‐en‐un dans Tuleap 10. Évalué à 1.
Merci !
Pas pour le moment, cela a été évoqué quelques fois mais ca n'a pas encore été formalisé en story. Peut etre lors d'une future refonte de cette vue.
Tu peux avoir un mur de cartes sur ta release également, de même nature de le kanban
C'est dans le backlog pour cette année (probablement second semestre).
[^] # Re: C'est choupinou
Posté par vaceletm (site web personnel) . En réponse à la dépêche Scrum, Kanban, Git Pull Request, Tests : tout‐en‐un dans Tuleap 10. Évalué à 4.
Le portage vers Centos7 est en cours, tout ce qui dépend des trackers (issues, agilité, etc) et de git devrait fonctionner mais globalement c'est en beta.
On a pas encore mis à jour le guide d'installation mais si vous voulez tester et rapporter les bugs, on donne les pointeurs sur chat ou la ML. Par contre, c'est fortement déconseillé en prod.
# Merci pour MailHog
Posté par vaceletm (site web personnel) . En réponse à la dépêche Trois outils pour développeur : MailHog, Tokei et Pandoc. Évalué à 6.
Je ne connaissais pas MailHog, c'est top et super facile à déployer sur une stack de dev déjà basée sur Docker.
Exemple en sur la base de code de Tuleap entre 2 meeting du lundi matin.
[^] # Re: TrafficLightsTM
Posté par vaceletm (site web personnel) . En réponse à la dépêche Scrum, Kanban, Git : Tuleap 9.0 est disponible . Évalué à 1.
Sur TrafficLights, tu peux trouver une première description dans la doc: https://tuleap-documentation.readthedocs.io/en/latest/user-guide/trafficlights.html
Grosso modo, pour l'instant il s'agit d'avoir un outil de gestion des campagnes de tests (manuels pour le moment). L'étape suivante sera de mettre en cohérence avec les exigences/stories pour offrir la traçabilité.
[^] # Re: Restler
Posté par vaceletm (site web personnel) . En réponse à la dépêche Tuleap 7.0 est disponible. Évalué à 4.
En fait la partie visualisation c'est du JS/HTML: https://github.com/Luracast/Restler-API-Explorer
Ca consomme un json craché par restler mais il n'y a pas de raison de ne pas pouvoir générer ça avec du java (à part peut-être la quantité de mémoire que ça va consommer)
[^] # Re: gantt
Posté par vaceletm (site web personnel) . En réponse à la dépêche Tuleap 7.0 est disponible. Évalué à 2.
La visualisation gantt est possible au dessus d'un tracker. Exemple bidon, nos sprints
Par contre avec les vraies données (start date, end date, completion & co) ça rend mieux. On l'utilise notamment pour visualiser nos congés (dans un tracker Tuleap, of course ;)).
Merci pour les encouragements !
[^] # Re: Gerrit
Posté par vaceletm (site web personnel) . En réponse à la dépêche Tuleap 7.0 est disponible. Évalué à 3.
Gerrit doit être installé à part (cf. la doc: https://tuleap.net/doc/en/user-guide/gerrit.html)
Mais il n'est pas nécessairement dédié à cela (ie. s'il y a déjà un serveur gerrit qui tourne, avec de la réplication et tout, Tuleap s'integre nativement et sans modifs).
D'ailleurs, on peut aussi avoir plusieurs serveurs Gerrit connectés en simultané (question de charge, de confidentialité, etc).
# Docker
Posté par vaceletm (site web personnel) . En réponse à la dépêche Tuleap 7.0 est disponible. Évalué à 7.
Je ne l'ai pas mis dans la news mais notre dernier jouet à la mode c'est Docker, si vous voulez tester du Tuleap dans du Docker c'est:
Plus d'info sur l'index docker
On essaye de documenter nos trouvailles ici sur le blog
[^] # Re: utilisable en production ?
Posté par vaceletm (site web personnel) . En réponse à la dépêche Sortie de Tuleap 6.0. Évalué à 0.
Tu utilises quoi à la place ?
[^] # Re: Les bons langages tout comme le bon chasseur...
Posté par vaceletm (site web personnel) . En réponse au journal Et si on faisait un "Who's hiring" à la linuxFr ?. Évalué à 10.
Pas du tout, efface!
C'est impossible d'écrire de la merde en Lisp puisque c'est fonctionnel.
En plus c'est plus dur à apprendre que Java donc ça s'adresse uniquement à une élite de développeurs/mathématiciens.
Vu que ça écreme les praticiens, le résultat n'est que meilleur (comme l'ENA, l'X ou epita).
[^] # Re: Le titre est trop long
Posté par vaceletm (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 1.
Puis
Ça m'a tout l'air d'un gros troll velu mais j'y vais quand même.
Un code conçu en TDD est refactorisable les doigts dans le nez, quelque soit le type de typage (ah ah) utilisé.
Et si ton langage de prédilection est java pour faire du test unitaire ou du TDD, je t'encourage vivement à regarder RSpec pour voir ce qu'un framework de test des années 2010 ressemble (et pourtant je ne suis pas un ruby-iste).
# Pas mieux chez les autres
Posté par vaceletm (site web personnel) . En réponse au journal Le SAV d'Orange ? Nul à ch*er !. Évalué à 10.
Au boulot on a Bouygues tel et une box qui déconne (pléonasme).
Lors d'une énième plainte au service client, je me suis vu reproché de connecter trop d’appareils à la box car il y avait plus de 5 éléments en réseau sur mon LAN. Comme ce sont les machines des personnes qui travaillent dans la boite, on ne peut pas les débrancher, du coup je demande ce que Bouygues propose.
L'opérateur me répond qu'il faut débrancher des machines (on tourne en rond). Je propose alors de licencier 3 personnes pour qu'Internet fonctionne, l'opérateur m'a répondu "oui voilà c'est ça". Je l'ai fait répéter et il a confirmé.