Journal Nan mais quoi comme gestionnaire de bugs ?

Posté par  .
Étiquettes : aucune
0
10
jan.
2008
Bonjour,

Mon cher institut qui me nourrit moi et mes futurs enfants (celui qui produit les indices que personne ne croît) réfléchit à se doter d'une plateforme collaborative externe pour pouvoir bosser correctement avec nos prestataires.

Dans un premier temps on s'intéresse à la partie "gestionnaire de bugs" de la plateforme.

A cette occasion j'aimerais bien pousser une solution open-source. En interne on bosse avec GForge, et euh..., ben c'est assez perfectible comme outil :-|

Lesquels avez-vous eu l'occasion d'utiliser ? Lequel conseiller en entreprise (ie devs neuneus nombreux) ?

J'aime bien Trac, mais il manque l'intégration avec CVS. J'aime bien Bugzilla, mais c'est du perl (moi j'ai rien contre, mais les admins web si). J'aime bien Jira, mais c'est payant et propriétaire...

Quelqu'un a utilisé Redmine ?

Bugzilla: http://www.bugzilla.org/
Jira: http://www.atlassian.com/software/jira/
Trac: http://trac.edgewall.org/
Redmine: http://www.redmine.org/
  • # Flyspray

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

    J'en suis ravi, et le logo est marrant ;)
    • [^] # Re: Flyspray

      Posté par  . Évalué à 3.

      Si tu cherche la simplicité, flyspray aussi.

      Un exemple de projet où il s'en serve : http://www.rockbox.org/tracker/index.php?type=2
      • [^] # Re: Flyspray

        Posté par  . Évalué à 3.

        idem, flyspray ça va bien, c'est léger, simple et efficace.

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: Flyspray

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Dans la boite qui me nourrit on l'utilise pour le suivit des réparations et les non-conformité.
      C'est génial comme soft surtout quand il vous dénonce à votre chef parce que vous avez oubliez une panne.
  • # mantis

    Posté par  . Évalué à 10.

    • [^] # Re: mantis

      Posté par  . Évalué à 2.

      C'est ce qu'utilise la DGME, peut être voir avec eux pour mutualiser ce qui peut l'être (éviter le gaspillage, toussa, expérience, connaissance).
      http://www.modernisation.gouv.fr/
      http://www.thematiques.modernisation.gouv.fr/
      http://admisource.gouv.fr/

      Peut être voir ce qu'ils ont sur les outils collaboratif.

      C'est leur raison d'être d'aider à la modernisation des administratons (si on parle bien d'un institut public).
      • [^] # Re: mantis

        Posté par  . Évalué à 1.

        Pas con, je vais regarder ce qu'ils font/proposent.

        A part ça, Admisource, c'est un GForge relooké. Les gestionnaire de bugs, c'est pas Mantis, c'est juste celui de GForge.
    • [^] # Re: mantis

      Posté par  . Évalué à 2.

      A l'époque ou je l'utilisais je ne le trouvais pas fabuleux mais correct.

      Maintenant je j'utilise CARS de Compuware (qui est aux bugtrackers ce que Lotus Notes est aux logiciels de messagerie) je suis nostalgique de Mantis qui faisait tout ce qu'on peut attendre de ce genre de logiciel avec simplicité et rapidité.

      BeOS le faisait il y a 20 ans !

    • [^] # Re: mantis

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

      Je plussoie.

      On utilise ca au boulot et c'est un plaisir en ce qui me concerne. On peut faire des workflow clairs, c'est simple a installer, simple a prendre en main et il fait tout ce dont j'ai besoin.

      Il y a des plugins pour faire de l'integration avec des SCM et pour faire des jolis graphes.
  • # Et pourquoi ne pas passer à Subversion ?

    Posté par  . Évalué à 2.

    Ainsi, vous pouvez utiliser Trac !
    C'est ce qu'on fait dans ma boite et ça marche très bien. En plus, il y a un Wiki. On peut facilement scripter Subversion pour modifier les tickets Trac.

    Mais si vous tenez absolument à rester avec CVS...
    • [^] # Re: Et pourquoi ne pas passer à Subversion ?

      Posté par  . Évalué à 4.

      Et pourquoi ne pas passer à Subversion ?


      Parce qu'au bout de quatre ans de CVS, une bonne partie des développeurs

      - soit n'utilisent pas du tout CVS
      - soit ne font qu'un commit (en fin de projet)
      - soit utilisent CVS mais ont du mal

      Je connais des devs qui refusent aussi d'utiliser un outil de gestion de versions, parce qu'ils sont "devs SQL", et que "CVS, c'est pas mon métier".

      Bref, faut aller doucement le matin, pas trop vitre l'aprèm, et on ralentit le soir.
      • [^] # Re: Et pourquoi ne pas passer à Subversion ?

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

        bôf, s'ils n'ont pas réussi à se mettre à CVS, il y a un risque qu'ils accrochent à Subversion... autant aller de l'avant (montrer svn2cl pour générer un changelog automatique aide pas mal, ainsi que les rapprochements bugs/version quand le BTS et le gestionnaire de source sont liés : en tout cas ça plaît aux chefs de projets).
      • [^] # Re: Et pourquoi ne pas passer à Subversion ?

        Posté par  . Évalué à 4.

        Parce qu'au bout de quatre ans de CVS, une bonne partie des développeurs

        - soit n'utilisent pas du tout CVS
        - soit ne font qu'un commit (en fin de projet)
        - soit utilisent CVS mais ont du mal


        Pourquoi veux-tu une intégration CVS si CVS est à peine utilisé.

        Je connais des devs qui refusent aussi d'utiliser un outil de gestion de versions, parce qu'ils sont "devs SQL", et que "CVS, c'est pas mon métier".

        Avec ce genre d'arguments tu peux leur répondre que "bug tracker, c'est pas mon métier".

        Ca a l'air agréable ta boîte, heu ton institut de statistiques.
        • [^] # Re: Et pourquoi ne pas passer à Subversion ?

          Posté par  . Évalué à 1.

          Évidemment je caricature un peu. Les équipes les plus en avance utilisent des gestionnaires de versions depuis plusieurs années (PVCS pour ne pas le nommer), et réclament un outil plus moderne que CVS. Les équipes les plus à la traine ne font pas de gestion de versions du tout. Entre les deux il existe une continuité de "solutions", genre serveur de partage de fichiers, ou sources dans une base de données (!).

          C'est donc déjà suffisamment le foutoir sans que l'on ajoute un système de plus (SVN si c'était le cas). Un jour prochain on le fera, quand on sera arrivé à des pratiques plus homogènes.

          Un autre argument, c'est que sur les sujets outils de développement/bug tracker/outils collaboratifs nous sommes... 1.
      • [^] # Re: Et pourquoi ne pas passer à Subversion ?

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        justement, si ils n'utilisent pas CVS ou peu, c'est peut être parce que CVS c'est franchement dépassé et franchement pénible à utiliser, non ? Et donc peut être que si vous migrez vers un outils plus moderne et plus simple d'utilisation...
        • [^] # Re: Et pourquoi ne pas passer à Subversion ?

          Posté par  . Évalué à 2.

          Boarf en ligne de commandes ça pue un peu, mais à travers Eclipse c'est assez potable. Il y a de nombreux arguments qui remontent pour ne pas utiliser CVS, et sa difficulté n'est pas le principal. C'est souvent le principe même de gestion de versions qui ne passe pas :-/

          Mais on ira vers SVN, c'est certain.
          • [^] # Re: Et pourquoi ne pas passer à Subversion ?

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

            Au passage, que ça soit sous Windows ou sous Linux, il y a des front-end graphiques à SVN et à CVS (si c'est la ligne de commande qui les rebutes).

            Je pense aux TortoiseXXX sous Windows, à kdesvn [et Gnome consorts sûrement] sous Linux, à RapidSVN sous les deux environnements. Sans parler des plugins qui s'intègrent directement dans certaines usines à gaz.

            Après, un petit Subversion et tu peux lui coller un Trac sur le dos. Y'a les outils pour passer de cvs à svn, ça permet d'harmoniser...

            Bon, j'essaie de motiver un chercheur pour qu'il passe d'archives de versions de son logiciel sous la forme de répertoires multiples (éventuellement compressés) vers Subversion... c'est dur (une techno de plus à apprendre, et c'est pas son job). Je compatis.

            Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

  • # launchpad

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

    launchpad marche pas mal:
    https://bugs.launchpad.net/
    • [^] # Re: launchpad

      Posté par  . Évalué à 7.

      çapusaipaslibre
      • [^] # Re: launchpad

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

        ho, je savais pas, j'étais persuadé que le bug tracker de ubuntu était forcément libre. Et en effet, j'y trouve pas de license... Ca me fait mal qu'inkscape y soit passé alors :/

        Bon sinon j'ai bien apprécié TRAC, déjà mensionné...
        • [^] # Re: launchpad

          Posté par  . Évalué à 2.

          Ce n'est pas qu'il n'est pas libre, il n'est juste pas distribué ! Impossible à installer chez soi donc.

          ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

  • # Jira

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

    Dans ma boite on utilise Jira depuis plus d'un an et il faut dire qu'il est :
    - facile d'accès
    - assez paramétrable (ex : Worflows, etc...)
    - très puissant au niveau reporting
    - il est possible de le brancher avec ton CVS
    - chaque utilisateur peut créer ses propres tableaux de bord ce qui est très appréciable

    Mais il a aussi quelques désavantages :
    - la traduction est pas toujours très pertinente, voir inexistante sur certains écrans
    - l'administration ne semble pas toujours être une partie de plaisir
    - the last but not the least : Jira capuesaipaslibre®... même si l'éditeur fait des efforts pour les projets Open Source : http://www.atlassian.com/software/jira/pricing.jsp#nonprofit
    • [^] # Re: Jira

      Posté par  . Évalué à 2.

      même si l'éditeur fait des efforts pour les projets Open Source


      Oui c'est vrai que Jira a le vent en poupe: les consultants n'arrêtent pas de le citer. Indépendamment de ça je le trouve bien foutu.

      Mais...

      Community licenses are designed for organisations which are:
      [...]
      non-government
      [...]


      En plus, j'aimerais bien être certain de pouvoir exporter les données en cas de changement inopiné de logiciel, et avec le propriétaire, je n'ai pas tellement confiance...
      • [^] # Re: Jira

        Posté par  . Évalué à 3.

        Les fonctions d'import/export de données sont bien faites d'apres ce que j'en ai vu. D'ailleurs en ce qui concerne l'export cela facilite bien des reportings...

        Et puis ils ont un t-shirt sympa :)
  • # Et Codex?

    Posté par  . Évalué à 1.

    Qui fait un peu tout cela...
    Vous ne connaissez peut être pas encore. C'est GPL.
    http://codex.xrce.xerox.com/fr/features.php
    -- LC
    • [^] # Re: Et Codex?

      Posté par  . Évalué à 0.

      - Le site a un bon gout de corporate. Très bien pour un business loto.
      - C'est GPL ? Tiens ça n'est pas spécifié sur le site.
      - Où est le lien pour télécharger les sources ?
      - Mais c'est-y pas un fork de GForge ou de Sourceforge ? Où elle est la référence ?
      - Il faut que je donne mon email, le nom de ma boîte, et le certificat de virginité de ma grand mère pour avoir plus d'informations ? C'est original pour attirer le chaland.
      • [^] # Re: Et Codex?

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

        le certificat de virginité de ma grand mère

        Tu serais donc le fils caché de Jésus ?
      • [^] # Re: Et Codex?

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

        - Où est le lien pour télécharger les sources ?

        Où est le lien pour télécharger le logiciel ? Les sources n'ont à être mises à disposition que des gens qui possèdent le logiciel.

        - C'est GPL ? Tiens ça n'est pas spécifié sur le site.

        Ce n'est pas obligatoire de le préciser. Certes, on pourrait voir ça comme un plus, un argument de vente, mais rien ne t'oblige à en faire la pub. Du moins, tant que tu ne fournis pas le logiciel.

        Pour le reste, tout à fait d'accord, le site pue des chaussettes. Mais il ne me semble poser aucun problème légal.
        • [^] # Re: Et Codex?

          Posté par  . Évalué à -1.

          Oui j'ai un bon feeling open-source là. En puis je suis sur que ça résoudra tout les problèmes de moinsser le message où je pose les questions.
  • # Redmine

    Posté par  . Évalué à 4.

    J'utilise Redmine quotidiennement depuis environ 1 mois, pour gérer un projet avec 7 personnes.

    Globalement, c'est Trac repensé en Ruby on Rails, avec la possibilité d'avoir plusieurs SCM.

    Au début, je dois avouer que j'étais trés surpris par la qualité générale de la chose par rapport à Trac ( je n'ai testé que Trac d'ailleurs à part Redmine ) puis au fil du temps, la jeunesse du projet à commencé à apparaître clairement. Légers bugs, placement d'options de configurations un peu hasardeuses, mais rien s'opposant à une gestion efficace du projet.

    Les fonctionnalités qui m'ont particulièrement plu ainsi qu'à l'équipe qui utilise le redmine en question sont : la possibilité d'avoir plusieurs trackers, plusieurs projets avec un repository séparé chacun, les workflows dans la gestion des status de tickets ( genre, un ticket "new" ne peut arriver en "fixed" sans passer par "awaiting validation" ).

    Un des inconvénients est qu'il n'y pas pour le moment d'api genre XML-RPC permettant de faire des choses sympatiques comme : http://blog.litchis.fr/jh/?p=12 , ni rien de trés Restful.

    Aprés, un autre point trés notable est la facilité d'installation de la chose ( par rapport à Trac ) , c'est à dire comme n'importe quelle application RoR.

    Pour conclure, c'est encore jeune, mais c'est prometteur et déjà utilisable.
    • [^] # Re: Redmine

      Posté par  . Évalué à 4.

      Je l'ai mis en place également le mois dernier, et j'en suis très satisfait. Je n'ai pas noté de bug pour l'instant.

      J'apprécie beaucoup la connection avec Subversion (au autre SCM) qui me permet de voir rapidement les révision concernées par une Issue (en mettant IssueId #1 dans le commit message, la révision est automatiquement attachée à l'Issue), la personnalisation des état des Issues (À développer, À recetter, Fermé, Rejeté ; par exemple) et des règles de workflow en fonction du profil de l'utilisateur. Ce qui m'a fait choisir ce produit plutot qu'un autre, c'est la possibilité de saisir le temps estimé de réalisation (sans utiliser un champ personnalisé), le pourcentage de réalisation, et surtout la saisie du temps passé (pointage de temps sur les Issues).

      La base de donnée est assez facile à prendre en main, ce qui fait que c'est assez facile à connecter avec un outil de reporting comme BIRT afin de générer des rapports personnalisés qui n'auraient pas été prévus par Redmine : somme des temps estimés pour les Issues affectés à une personne, à une version ; résumé du temps passé par Issue / par Jour / par Personne ; etc.

      Et comme Jhc_ l'a dit, c'est très simple à installer, tout en français, et l'interface est agréable. Bref, très content !
  • # Libresource

    Posté par  . Évalué à 5.

    On en a déjà parlé plusieurs fois ici.
    http://linuxfr.org/2006/11/23/21676.html
    et c'est écrit par des petits gars de chez nous.

    Ca supporte SVN et pas CVS
    http://linuxfr.org/2007/01/25/21964.html
    mais honnêtement il n'y plus guère de raison d'utiliser CVS aujourd'hui avec un remplaçant qui supporte la mémoire de merge
    http://blogs.open.collab.net/svn/2007/09/what-subversion.htm(...)
    qui gère le versionning des répertoires
    qui dispose d'un CLI semblable à CVS
    qui permet de tagger en un temps record (cheap copy)
    et qui a plein d'autres avantages.
    http://subversion.tigris.org/

    Sinon pour en revenir à libresource, en plus c'est écrit en java et pas en perl ni en PHP ruby ou autre pyhton et ca parle au daiiiicideurs.
  • # Redmine

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

    Un article sur le gestionnaire de projet :
    http://00f.net/2007/a-wonderful-project-management-tool

    Pour redmine Je n'ai fait que testé (donc pas en production).

    Cela me semble un bon choix.
    Moins lourd que gforge & Co.
    Plus complet et moins limité que Trac.
  • # Merci !

    Posté par  . Évalué à 1.

    Merci de votre aide !

    Finalement la sagesse et le prudence l'ont emporté: pour le moment on a choisi Mantis....

    Je mettrai un petit message dans les journaux quand on aura mis en place une plateforme collaborative externe !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.