Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net

Posté par  . Édité par Davy Defaud, Nils Ratusznik et ZeroHeure. Modéré par ZeroHeure. Licence CC By‑SA.
51
8
juin
2018
Gestion de versions

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.

Outils de planification et de suivi de projet sur Tuleap

À vous de jouer ! Nous, on héberge et on maintient.

Aller plus loin

  • # Bravo !

    Posté par  (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  (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  . Évalué à 5.

    Je trouve que cette ouverture est très bien. Mais :

    • Je n’ai pas trouvé comment explorer les dépôts libre/public sans créer de compte.
    • La force de github, gitlab c’est la facilité de collaborer en ayant malgré tout chacun son espace.

    N’ayant pas encore eu le temps de m’inscrire, comment ça se passe sur les points ci-dessus ?

    • [^] # Re: Super Nouvelle

      Posté par  (site web personnel) . Évalué à 10.

      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)

      • [^] # Re: Super Nouvelle

        Posté par  (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  . É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  (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  (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  (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:

    • la version docker était minimale
    • la version brute quant à elle était faite pour des bases red-hat. De plus de souvenir des ports requis pas Tuleap était en conflit avec ceux déjà utilisée par nos différents autres services. On ne pouvait pas configuré un autre port. Ils étaient imposé par tuleap !!

    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  . É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  (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  (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  (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  . É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  (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  (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  (site web personnel) . Évalué à 10.

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

      • [^] # Re: Quel courage :

        Posté par  (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  . É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.

  • # Complicité de collecte de données personnelles pour Google ?

    Posté par  . Évalué à 1.

    Nous n'avons pas été en mesure d'affirmer que vous n'êtes pas un robot, merci de réessayer

    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  (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  . É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  (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  . Évalué à 3.

            ajoutions l'accord pour utiliser le captcha de google

            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  (site web personnel) . Évalué à 5.

              Et utiliser un captcha en logiciel libre, cela ne serait-il pas mieux ?

              Je n'en connais pas d'efficace mais je suis preneur de retour d'expérience sur le sujet.

              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 :-/

              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  . Évalué à 2.

                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.

                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  . Évalué à 1. Dernière modification le 28 juin 2018 à 13:50.

                  il me semble que Google a une politique anti-Tor.

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