L’équipe Tuleap a le plaisir de vous annoncer qu’elle vient d’ouvrir la plate‐forme Tuleap.net à tous les projets libres et open source.
La plate‐forme Tuleap.net, basée sur l’outil Tuleap, hébergeait jusqu’à maintenant uniquement le projet Tuleap en lui‐même. Devant le dernier buzz dans le monde du développement qui ne vous aura pas échappé (Microsoft rachète GitHub), nous avons décidé de nous lancer : on vous accueille tous, avec plaisir et l’on partage cette plate‐forme aux fortes fonctionnalités.
Pourquoi ? Parce que certains d’entre vous verrons dans cet évènement, l’occasion de faire le point : sur leur engagement envers le Libre, sur ce dont ils ont besoin en termes d’ingénierie logicielle et de gestion de projet.
Avec Tuleap.net, vous allez pouvoir :
- planifier et suivre vos projets : soit avec une vue type Scrum, soit avec les tableaux Kanban ;
- créer et suivre vos tâches, stories, exigences, bogues, etc. ;
- héberger votre code avec Git, en discuter avec les discussions en ligne ou utiliser Subversion ;
- gérer vos documents, mettre des flux d’approbation ;
- faire des campagnes de tests manuels et automatisés.
Pour rappel, voici tout ce que Tuleap offre dans sa version 10, présentée le mois dernier.
Ça vous tente ? Seule condition, que votre projet soit public et open source.
À vous de jouer ! Nous, on héberge et on maintient.
Aller plus loin
- Créez votre compte sur Tuleap.net (693 clics)
- Suivez‐nous sur Twitter (97 clics)
- Site du projet Tuleap (662 clics)
- LinuxFr.org : Scrum, Kanban, Git Pull Request, Tests : tout‐en‐un dans Tuleap 10 (379 clics)
# Bravo !
Posté par Yves (site web personnel) . Évalué à 10.
Bravo, non seulement pour cette proposition généreuse — même si ça peut être gagnant-gagnant ;-) —, mais aussi pour oser conserver (et proposer, du coup) vos spécificités, votre vision des choses, face à la pullulation des GitHub-like (GitHub, GitLab, Gogs, Gitea…).
[^] # Re: Bravo !
Posté par vaceletm (site web personnel) . É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 !
# Super Nouvelle
Posté par Anthony Jaguenaud . Évalué à 5.
Je trouve que cette ouverture est très bien. Mais :
N’ayant pas encore eu le temps de m’inscrire, comment ça se passe sur les points ci-dessus ?
[^] # Re: Super Nouvelle
Posté par vaceletm (site web personnel) . É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: Super Nouvelle
Posté par Mathias Bavay (site web personnel) . Évalué à 2.
Une question qui me taraude depuis la première publication de cette dépêche, à propos de la navigation anonyme: est ce qu'il est possible de laisser certaines pages accessible sans s'enregistrer (une page de téléchargements, une page de présentation du projet, une page éventuellement pour naviguer dans les sources)? Pour nous, c'est (c'était) la grande force d'Indefero, pouvoir utiliser la forge aussi comme page ou les utilisateurs lambda peuvent télécharger nos release (et de la doc). Le gros intérêt est la simplicité (pas besoin de gérer un second site pour cela) et que notre doc peut aussi être indexée par les moteurs de recherche.
Mathias
# Concurent de Jira+bitbucket ?
Posté par Mimoza . Évalué à 4.
Des quelques fonctionnalité que tu cite j'ai plus l'impression d'avoir a faire a un Jira+bitbucket-like, je me trompe ?
Sinon très bonne initiative cette ouverture !
[^] # Re: Concurent de Jira+bitbucket ?
Posté par vaceletm (site web personnel) . É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: Concurent de Jira+bitbucket ?
Posté par Bruno (Mastodon) . Évalué à 3. Dernière modification le 09 juin 2018 à 13:27.
C'est plutôt un concurrent de Redmine : https://www.redmine.org/
Redmine est présent depuis très longtemps et c'est aussi un projet Français à l'origine.
Le docker Redmine fonctionne très bien et facile à utiliser.
Les deux sont biens…
# Installation compliquée et peu paramétrable
Posté par Jonathan MERCIER (site web personnel) . Évalué à 3. Dernière modification le 08 juin 2018 à 14:40.
J'avais essayer d'installer tuleap il y a quelque temps et ce fut un échec:
Bref déçu à l'époque de l'outil, gitlab fut essayé ensuite et a nécessité quelques heures seulement pour une mise en production avec backup et tout..
[^] # Re: Installation compliquée et peu paramétrable
Posté par Wawet76 . Évalué à 7.
J'ai même pas essayé de l'installer alors que ça semble faire exactement ce qu'on cherche dans mon équipe.
En voyant que c'était du LAMP je me suis dit que ça allait être simple à installer et administrer. La douche froide en voyant que les seules instructions sont pour Docker (faudra que je m'y mette un jour, mais ça me donne des boutons) ou CentOS 6…
[^] # Re: Installation compliquée et peu paramétrable
Posté par vaceletm (site web personnel) . É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: Installation compliquée et peu paramétrable
Posté par Mathias Bavay (site web personnel) . Évalué à 6.
Cela fait plus d'un an que je suis tenté par Tuleap pour remplacer notre Indefero vieillissant, mais j'ai toujours repoussé la migration pour les raisons suivantes:
1) version totalement en fin de vie de php (pour ce qui est de la sécurité, ce n'est pas une super pub);
2) usage quasi obligatoire de docker ou Centos/RH 6 (nous avons tout le reste sur du Debian);
Sinon, je suis bien convaincu par les possibilités de l'outil, mais je traîne encore les pieds à cause de ces deux points (même si Tuleap est passé sur du php un peu plus récent, c'est encore du php 5.6 dont le support s'arrête en décembre 2018!).
[^] # Re: Installation compliquée et peu paramétrable
Posté par vaceletm (site web personnel) . É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: Installation compliquée et peu paramétrable
Posté par ohmer . Évalué à 4. Dernière modification le 09 juin 2018 à 03:41.
J'ai été très surpris d'apprendre que Tuleap était une application PHP mais qu'elle avait une grosse dépendance envers RHEL/Centos. Qu'est-ce qui vous restreint à du RHEL/Centos? Par exemple, pourquoi ça ne fonctionne pas sous Ubuntu avec le PPA permettant d'installer PHP 5.6?
En général, les apps PHP sont très portables, d'où mon incompréhension.
[^] # Re: Installation compliquée et peu paramétrable
Posté par vaceletm (site web personnel) . É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.
# Quel courage :
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 4.
On est d'accord : GitHub se fait racheter par Microsoft car ils ne gagnent pas assez d'argent (pour faire l'inverse ?). Et si c'est le cas, c'est certainement en partie du fait qu'héberger gratuitement beaucoup de projets libres, ça coûte de l'argent (serveurs, main d'oeuvre) et que ça ne rapporte rien (du moins directement).
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 ?
Cf. https://www.developpez.com/actu/82986/SourceForge-pointe-du-doigt-pour-la-diffusion-des-adwares-la-plateforme-supprime-le-malware-Binkiland-de-ses-installateurs-suite-a-des-plaintes/
Autrement dit : comment Enalean va financer l'hébergement massif de projets gratuits ?
[^] # Re: Quel courage :
Posté par vaceletm (site web personnel) . É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: Quel courage :
Posté par David Demelier (site web personnel) . Évalué à 1.
GitHub n'est pas pauvre. N'oubliez pas qu'il y a aussi des entreprises et particuliers qui payent pour des dépôts privés.
git is great because linus did it, mercurial is better because he didn't
# intégration de Hg
Posté par FilG . Évalué à 3.
Bonjour,
j'ai cru comprendre sur votre site que Git et SVN sont intégrés, prévoyez-vous d'intégrer Mercurial (Hg) ? :)
Merci.
[^] # Re: intégration de Hg
Posté par vaceletm (site web personnel) . É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: intégration de Hg
Posté par David Demelier (site web personnel) . Évalué à 2.
Oui c'est aussi la première chose que j'ai regardée, dommage.
git is great because linus did it, mercurial is better because he didn't
# Complicité de collecte de données personnelles pour Google ?
Posté par cpm . Évalué à 1.
Impossible de se créer un compte si on n'accepte pas le captcha de Google.
Est-ce compatible RGPD ? Possibilité de faire disparaître cette barrière incompatible avec les valeurs du Libre ?
L'avantage de votre initiative, ce sont aussi les retours des utilisateurs <3
Avec tous mes encouragements.
[^] # Re: Complicité de collecte de données personnelles pour Google ?
Posté par vaceletm (site web personnel) . É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: Complicité de collecte de données personnelles pour Google ?
Posté par cpm . Évalué à 10.
À partir du moment où dans ta page web, tu inclus une ressources externe, ici https://www.google.com/recaptcha/api.js, ça provoque une requête HTTP(S) et donc une trace dans les logs chez Google avec plein d'information sur le webonaute. Ces données sont utilisables/utilisées pour tracer/fliquer/espionner les gens partout.
Donc, explicitement, tu permets à un tiers de collecter des données personnelles (de navigations) et de les exploiter (analyse, revente, etc.), et ce en dehors de l'Union européenne… Or, ni pour la collecte, ni pour l'exploitation, vous ne demandez un consentement préalable. D'où une infraction au RGPD.
Utiliser un captcha est effectivement sage, mais pour un projet sous licence GNU GPL, c'est étonnant de voir utiliser un logiciel non libre (captcha Google).
Je réitère mes encouragements…
[^] # Re: Complicité de collecte de données personnelles pour Google ?
Posté par vaceletm (site web personnel) . É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: Complicité de collecte de données personnelles pour Google ?
Posté par cpm . Évalué à 3.
Et utiliser un captcha en logiciel libre, cela ne serait-il pas mieux ? Parce que si pour utiliser tuleap.net il faut se soumettre à Google … l'intérêt de l'offre perd énormément de son intérêt :-/
Sans compter que cela attise le doute quant à l'adhésion des gestionnaires du projet aux valeurs du Libre, ce qui serait très dommage :-/
[^] # Re: Complicité de collecte de données personnelles pour Google ?
Posté par vaceletm (site web personnel) . Évalué à 5.
Je n'en connais pas d'efficace mais je suis preneur de retour d'expérience sur le sujet.
A l'heure actuelle le captcha n'est présent qu'a l'enregistrement du compte ce qui n'arrive qu'une seule fois. Cette enregistrement peut être réalisé en mode incognito ce qui va considérablement limiter la quantité d'informations envoyées à google pour cette seule et unique requete faite auprès de ce service.
[^] # Re: Complicité de collecte de données personnelles pour Google ?
Posté par RyDroid . Évalué à 2.
Une personne qui veut s'enregistrer ne le sera probablement pas. C'est généralement un mauvais signe d'utiliser Google. Par exemple, pour moi, ce genre de captcha engendre la fermeture de l'onglet, je ne vais donc pas plus loin. De plus, il me semble que Google a une politique anti-Tor.
[^] # Re: Complicité de collecte de données personnelles pour Google ?
Posté par voxdemonix . Évalué à 1. Dernière modification le 28 juin 2018 à 13:50.
Ca dépends des jours. Pour le moment ça va (testé avant hier) mais parfois c'est la galère.
Mais il faut avouer qu'à part celui de google, les captchas se font généralement cracker super vite.
# Gestion de la signature des commits git ?
Posté par amdg . Évalué à 2.
Bonjour,
Merci pour le travail de fond qui est réalisé pour moderniser l'interface utilisant Tuleap au travail je suis content de voir les mises à jour arriver au fur et à mesure.
Est-ce que vous pensez ajouter la gestion des signatures GPG dans git ? Actuellement ça rends très peu lisible le navigateur git web. Pas forcément une intégration comme GitHub ou GitLab, mais au moins un truc qui cache la signature par défaut et propose de l'afficher si l'utilisateur le souhaite. Pas besoin de la vérifier pour une première itération.
Merci encore pour votre boulot, n'ayant pas vraiment le choix de la forge qu'on utilise j'apprécie chaque mises à jour qui rendent Tuleap de plus en plus utilisable pour moi :)
AMDG
[^] # Re: Gestion de la signature des commits git ?
Posté par vaceletm (site web personnel) . É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: Gestion de la signature des commits git ?
Posté par vaceletm (site web personnel) . Évalué à 1.
J'oubliais.
L'entreprise pour laquelle vous travaillé finance peut être déjà des évolutions de Tuleap, rentrer en contact avec ces personnes peut être un bon moyen de faire avancer le sujet.
[^] # Re: Gestion de la signature des commits git ?
Posté par amdg . Évalué à 0.
Ah oui, je pense que l'on finance déjà Tuleap, je travaille chez un fondeur franco-italien ;)
Je vais me rapprocher de l'IT pour qu'ils vous remontent le besoin.
# Very nice !!
Posté par labbenes . Évalué à -2.
Top top la news !!! Bravo et que du succès.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.