Journal Gestionnaire de sources et bugtracker

Posté par  (site web personnel) .
Étiquettes : aucune
0
7
oct.
2005
Bonjour,


J'ai beau faire le tour des fonctionnalités des gestionnaires de sources (SVN,CVS principalement) et des bugtrackers, jamais je n'ai vu de liaison entre les deux.

Pourtant je trouve que ca serait une fonctionnalité intéressante. Pourquoi ? Parce que je me suis rendu compte que lorsque je corrigais un bug ouvert sur le bug tracker, je mettais toujours un commentaire équivalent dans la solution avant de le fermer et dans le commentaire du "commit".

En plus ca permettrait de pouvoir retrouver la partie de code qui a été corrigée si le bug est réouvert.
Et dans ce cas on pourrait voir que :
- soit le code corrigé n'est pas bien corrigé
- soit depuis la correction, il y a eu des modifications qui ont entraîné une régression
- ...

Enfin bon, ptêt que ca soulève un tas de problématique que je vois pas, ptêt que ca existe déjà, enfin bon, c'est un peu aussi à ça que tu sers journal, à me donner ton avis éclairé, alors merci d'avance !

  • # Trac ?

    Posté par  . Évalué à 10.

    http://projects.edgewall.com/trac/(...)

    Dam

  • # hé oui c'est dommage...

    Posté par  . Évalué à 1.

    il existent des outils proprio qui te permettent de faire la laison comme suit :

    bug-traker : tu cré ta change request
    svn/cvs-like : tu cré une ou plusieur "taches" de développement qui son liées à ta change request
    snv/cvs-like : tu lie un ou plusieurs fichiers sources à ta/tes "taches"

    donc depuis une demande de correction/demande d'evolution tu peux dire "cette demande à nécéssité plusieurs développements." et ensuite entrer plus profond dans la granularité "chaque développement à impliqué tel(s) fichier(s) source".

    c'est clair qu'il y a un manque dans l'open source à ce niveau la.
    j'aimerai de manière simple pour dire "la release N+1 est constituée de la release N et de l'ensemble de demandes de changement suivantes. Ces demandes de changements ont impliqués plusieurs développements", "ces developpements ont impliqués tels et tels fichiers sources" .....


    un jour peut etre ...

  • # mantis

    Posté par  . Évalué à 5.

    mantis http://mantisbt.org/(...) permet une intégration de subversion et cvs.
    cf
    http://manual.mantisbt.org/manual.configuration.source.control.inte(...)

    sinon http://freshmeat.net/projects/scmbug(...)

    "Scmbug is a system that integrates software configuration management (SCM) with bug-tracking. It aims to be a universal tool that will glue any source code version control system (such as CVS, Subversion, and Arch) with any bug-tracking system (such as Bugzilla and Mantis)."


    voilà, voilà :

    • [^] # Re: mantis

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

      Les 2 ont effectivement l'air de partir dans la direction que je veux.

      Je peux pas les tester maintenant (suis au boulot là), mais à lire les posts des gens, j'ai l'impression que c'est encore assez récent comme concept, et tout ce que permet cette intégration n'a pas l'air bcp exploitée.
      Comme le dit thomas dans un post précédent, ca pourrait être pas mal aussi de savoir quelles corrections de bugs/ajouts de fonctionnalités ont été faites entre 2 versions, et quels fichiers ont été modifiés.

      En tout cas c'est déjà une bonne chose que ca existe, je suis sûr que ca va évoluer, et je savais que qqu'un avait déjà pensé à ça avant moi ;) .

      merci pour ces liens

  • # Pourquoi ne pas utiliser les hébergeurs existant ?

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

    Comme https://gna.org(...) ou http://developer.berlios.de/(...) ? Services :
    - SubVersion (avec suivi des commit en HTML/texte par liste de diffusion ;-))
    - Suivi des bugs / patchs / demande de fonctionnalité
    - Liste(s) de diffusion
    - Gestion des droits d'accès avec une interface sympa
    - Hébergement de fichiers et/ou de site web
    - Gestion des actualités
    - Interface multi-langue ;-)
    - etc.

    Les interfaces de consultation des dépôts SubVersion sont plutôt jolis et permettent de naviguer entre les différentes révisions / branches. Exemples :
    http://svn.berlios.de/viewcvs/happyboom/happyboom/trunk/(...) (berlios)
    http://svn.gna.org/viewcvs/wormux/trunk/(...) (gna)

    Je trouve ces hébergements génialissimes. Bien sûr, on ne peut pas modifier les options de SubVersion spécifiquement pour notre projet.

    Haypo

  • # Chez KDE

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

    Lorsque que on fait un commit dans le SVN de KDE, on peut ajouter dans le log des mot clef comme
    BUG: 123456


    Cela va automatiquement fermer le bug 123456 sur le bugzilla de KDE, avec comme commentaire, le log, la révision, les fichiers modifiés, et éventuellement le diff s'il est petit.

    C'est un peu ce que tu demande, et je trouve ça effectivement très pratique.

  • # Aegis

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

    http://aegis.sourceforge.net/(...)

    Aegis va même plus loin puisque c'est un outil de gestion de configuration complet. En fait, pour lui, la problématique est inverse : il faut d'abord ouvrir un fait technique (fiche de bug ou de modification) avant de pouvoir accéder aux sources en modification.


    Sinon, j'avais trouvé une surcouche à SVN qui se branche à un suivi de bug. Mais j'ai pas le nom sous la main. Si je le retrouve, je poste ici.

  • # PDTI

    Posté par  . Évalué à 1.

    PDTI ( http://www.ravenbrook.com/project/p4dti/(...) ) permet l'integration entre Bugzilla et Perforce dans ma boite et ca marche pas trop mal

    • [^] # Re: PDTI

      Posté par  . Évalué à 2.

      La différence c'est que Perforce supporte intrinséquement la notion de demande de changement. Tu peux même affecter un fichier que tu es en train d'editer à une autre demande.
      Ce genre d'intégration est assez courante avec des logiciels proprio
      (Perforce, ClearcQuest/UCM Clearcase)

      Le gros avantage c'est que la gestion des demandes changements est centralisée.
      La demande doit exister avant que tu ne puisses modifier un changement. Cette demande est créée en genéral par le chef de projet qui a fait un travail de classement préalable(bug, feature request, enhancement, refusée, ...)
      Le développeur se voit affecté une liste de demande ou consulte la liste complète et en choisit une.

      L'intégration avec l'outil de version fait que 2 developpeurs ne prendront pas en charge la même demande et ne se marcheront pas sur les pieds, ce qui n'est pas le cas avec les gestionnaires classiques
      (si le developpeur oublie de consulter le bugzilla, rien ne l'empêche de modifier les fichiers pour un changement déjà pris en compte alors qu'il est obligé de consulter dans l'uatre cas ou de créer un changement doublons qu'un petit copain ne manquera pas de lui rappeler)

      Pour plus de souplesse l'outil doit accepter que le développeur puisse se créer une demande de changement (demande oubliée, décomposition d'une changement, ...) mais ca reste une politique à définir.

      Enfin, il faut bien noter que plusieurs changements peuvent concerner les même fichiers donc l'exclusivité sur un changement n'implique pas un jeton d'exclusivité sur un fichier.

      Je n'ai pas regardé comment fonctionne l'intégration trac/SVN mais je pense qu'il faudrait modifier SVN pour obtenir les mêmes fonctionnalités (on pourrait s'appuyer sur les properties mais qu'il faut implementer la gestion de l'exclusivité sur le changement)

      • [^] # Re: PDTI

        Posté par  . Évalué à 2.

        Ah autre chose aussi.

        Perforce offre un avantage en terme de tracking.
        Lorsqu'on traite un changement, tous les fichiers sont en lecture seule.
        Pour modifier ce fichier , il faut le demander explicitement (p4 edit).
        Ainsi, il y a une mise à jour sur le serveurr qui centralise le suivi des changements et on voit quels fihiers sont imcpactés en temps réels.
        Cela permet une gestion plus fine.

        Encore une fois ca ne signifie pas que le fichier est locké.

        Ce genre centralisation de suivi me parait plus difficile avec les outils distribués (Arch & Co) car nécessite une communication serveur qui va à l'encontre de la philosophie des DRCS. Ce n'est pas un troll.

        Et pour finir Perforce est gratuit pour les projets libres. Donc essayez le ca donnera peut -être des idées pour améliorer les outils libres.
        (Je ne sais pas si il y a une clause à la Bitkeeper en revanche)

  • # launchpad

    Posté par  . Évalué à 1.

    launchpad.net associe à la fois gestion des sources et bugtracker, en ayant une approche plus globale.
    la remonté des fix se fait via le gestionnaire de source dont la branche en général porte le nom et numéro du bug.

Suivre le flux des commentaires

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