Forum Programmation.autre "Nécessaire" de démarrage pour développement d'un projet libre.

Posté par . Licence CC by-sa
Tags : aucun
3
26
juin
2013

Bonjour.

Je suis en train de tenter de recenser la "boite à outils" de développement de projet libre.

Actuellement voici ce que j'ai relevé :

  • 1 gestionnaire de version (avec accès aux sources sur le net) pour héberger les sources
  • 1 bugtracker
  • un outil permettant de tracer les demandes d'évolution (hors bugs) => intégré au bugtracker ?
  • 1 site web (donc de préférence nom de domaine et hébergeur)
  • 1 wiki, éventuellement 1 blog permettant de suivre les évolutions du projet
  • 1 gestionnaire de documentation qui pourra agréger la doc générée par les outils xdoc, les documents d'utilisation, d'administration et de développeur

Voyez-vous d'autres outils ? y a-t-il des services en ligne offrant tout ou partie de ces outils (voire plus) ?

Merci pour votre retour.

  • # Github.

    Posté par (page perso) . Évalué à 1.

    À part ton gestionnaire de documentation, tu auras tout ça dans github[1]. Peut-être aussi gitorious. Peut-être aussi sourceforge. (mais comme je ne les utilise pas, je ne peux en jurer).

    [1] en mettant les demandes d'évolution dans les tickets, mais comme il y a un système de tags, tu auras le tag bug et le tag enhancement (de base je crois).

    It's a fez. I wear a fez now. Fezes are cool !

    • [^] # Re: Github.

      Posté par (page perso) . Évalué à 2.

      je crois que GitHub n'est pas vraiment libre (à moins qu'il le soit devenu au fil du temps), donc le conseiller pour le développement d'un projet libre, sur ce site pourrait être considéré comme quoi ?
      un lancé de troll avant l'heure ? :-)

      ma source : pourquoi githup saimal
      pour les dicaïdors pressés : ce journal, datant de 6 mois propose quelques alternatives

      Envoyé depuis mon Archlinux

      • [^] # Re: Github.

        Posté par (page perso) . Évalué à 1. Dernière modification le 27/06/13 à 00:13.

        Moui m'enfin bon.

        Ok, github, saymal, mais :

        • y a tout ce qu'il lui faut dedans
        • c'est quand même simple d'utilisation
        • ça ira vite à mettre en place
        • ça donne une bonne visibilité au projet.
        • c'est gratuit quand on laisse le dépôt en public (visualisation des fichiers + git clone) ce qui est bien puisque c'est ce qu'on cherche avec un projet libre.

        It's a fez. I wear a fez now. Fezes are cool !

        • [^] # Re: Github.

          Posté par . Évalué à 3.

          Avec ta logique, on peut en dire autant de tous les outils Google alors :-)

          • y a tout ce qu'il faut dedans
          • c'est quand même simple d'utilisation
          • ça va vite à mettre en place
          • ça donne une bonne visibilité au projet
          • c'est gratuit

          Et pourtant …

          Si vous n'aimez pas ce commentaire c'est qu'il est ironique.

          • [^] # Re: Github.

            Posté par (page perso) . Évalué à 1.

            y a tout ce qu'il faut dedans

            Bah, je suis pas sûr que tu puisse faire le site du projet directement avec google code. Alors que Github, si.

            ça donne une bonne visibilité au projet

            moins que sur github.

            Plus, on a des trucs à reprocher à Google (Prism, scannage des emails, publicité, toussa), mais Github ? À part que tous les bouts du site ne sont pas libres, que c'est une entreprise et qu'il faut passer par une API pour récupérer toutes tes billes ?

            Sourceforge a aussi des Terms of use qui peuvent puer ("In addition, we may share your personal information with affiliated companies.", dans http://slashdotmedia.com/terms-of-use/ que j'ai trouvé en allant sur https://sourceforge.net/user/registration), c'est aussi une entreprise…

            Bref, j'ai juste conseillé un truc rapide, simple, et qui pue pas trop. Après, j'aurais pu conseiller un redmine ou autre, mais là ça demande de l'investissement, une machine, toussa.

            On n'est pas trolldi, donc on va s'arrêter là, ok ?

            It's a fez. I wear a fez now. Fezes are cool !

  • # Taille de la communauté

    Posté par . Évalué à 3.

    Je ne vois pas d'autres outils particuliers.

    Le gestionnaire de version est vital. Ensuite, il faut voir tes habitudes et la taille de la communauté autour du logiciel. Avec trop d'outils l'utilisateur va se retrouver dans un cas où on lui répond sur le forum "regarde le wiki", puis ne trouvant pas l'info sur le wiki, le forum lui conseil d'envoyer un message à la mailing-list pour finir par ouvrir un bug sur le bug tracker (situation vécu).

    Tu peux utiliser une liste de diffusion qui fait tout. Ou un forum. Ou github et autres bitbuckets qui font même gestionnaire de version.

    • [^] # Re: Taille de la communauté

      Posté par . Évalué à 2.

      Merci pour ces retours. Le choix des outils est un autre problème (je vais regarder ce qui se fait et choisirai en fonction de ce que je trouve plus ou moins pratique).

  • # Redmine

    Posté par . Évalué à 1.

    Si tu ne veux pas utiliser un service en ligne, tu peux utiliser Redmine aussi…

    • [^] # Re: Redmine

      Posté par . Évalué à 2.

      J'allais être plus général en t'indiquant de prendre une forge logicielle. ça regroupe tout ce que tu liste avec en plus d'autres outils.

      Par contre je rejoins Elwood_Blues et je te conseille également redmine qui en plus d'être assez simple d'utilisation, répond à tout les besoins que tu a listé avec en plus quelques outils supplémentaire comme les forums, la getion de roadmap, l'espace de dépots des fichiers (utile pour le téléchargement de ton projet quand il sera finis ;-).
      bref je ne peu que te conseiller d'aller voir leur site (ils utilisent redmine pour le gérer : http://www.redmine.org/

      • [^] # Re: Redmine

        Posté par . Évalué à 2.

        Quand je vois ça : "Written using the Ruby on Rails framework, it is cross-platform and cross-database." , je me dis que ça ne peut être que très bien (pas de serpent affreux en vue … ;)

        Merci, je vais jeter un oeil … J'en avais entendu parler à plusieurs reprise (notamment lorsque je m'étais mis à RoR), mais jamais éprouvé le besoin de l'utiliser jusque maintenant.

    • [^] # Re: Redmine

      Posté par (page perso) . Évalué à 1.

      cet après-midi j'ai appris qu'il était possible de lier un commit de subversion (et peut-être de git) avec une demande/tache redmine de telle façon qu'en examinant une demande redmine on peut explorer les modifications de code qui ont été nécessaire pour la résolution de la dite demande, sans quitter redmine, pratique pour savoir qui à fait quelle modif pour résoudre la demande, simplement en saisissant le N° de demande redmine dans le commentaire du commit,
      c'est pas out of the box, il faut configurer à la mano la liaison, mais c'est quand même sympa comme fonctionnalité

      Envoyé depuis mon Archlinux

  • # tout en un sans prise de tête

    Posté par (page perso) . Évalué à 3.

    http://fossil-scm.org

    http://devnewton.bci.im

  • # De la juste proportion

    Posté par (page perso) . Évalué à 2.

    J'avais écrit un journal à ce sujet:
    https://linuxfr.org/users/sygne/journaux/publication-de-petits-projets
    Il y a plein de remarques intéressantes dans les commentaires.

    Je me demande si ce que tu cherches est bien proportionnel à l'envergure de ton projet. Pour avoir bugtracker complet, site, wiki, et blog, il faut déjà avoir une bonne communauté autour du projet. S'il y a déjà une communauté, autant lui demander de l'aide pour mettre en place ces outils, qui demandent tous du temps à administrer.

    Si ton projet est naissant, les outils les plus importants sont de loin le gestionnaire de version, et, àmha, le gestionnaire de documentation. Un gestionnaire de documentation bien fait devrait te permettre de créer des pages html statiques comme des pages de manuel: c'est suffisant pour faire un site. Ces outils sont finalement assez rares. Je te conseille d'utiliser en priorité l'outil écrit dans le langage de programmation de ton projet: ce sera mieux intégré, et tu sauras le modifier si besoin.

    Pour la communauté, une adresse mail, indiquée dans le README, suffit largement au début, tant pour les rapports de bogues, les demandes d'informations, que les patchs. C'est en outre bien plus convivial qu'un bug tracker: tu recevras quelques mots d'encouragement en plus des contributions. Il faut juste prendre soin d'indiquer pour chaque commit qui est à l'origine du rapport de bogue, de la requête ou du patch, pour garder des traces claires et publiques des contributions.

    À titre d'exemple, pour mon projet Utroff, j'utilise troff lui-même pour produire toute la documentation (documentation gérée par les outils appropriés au langage de programmation), mon gestionaire de version est local (RCS), il y a une adresse mail pour les discussions, et un compte twitter (mort) pour les nouvelles. Mettre en place tout cela, et faire des archives propres (avec readme, licence, changes, manuel) prend déjà beaucoup, beaucoup, beaucoup de temps.

    • [^] # Re: De la juste proportion

      Posté par . Évalué à 2.

      Je me demande si ce que tu cherches est bien proportionnel à l'envergure de ton projet. Pour avoir bugtracker complet, site, wiki, et blog, il faut déjà avoir une bonne communauté autour du projet. S'il y a déjà une communauté, autant lui demander de l'aide pour mettre en place ces outils, qui demandent tous du temps à administrer.

      Disons que tant qu'à faire si un ou plusieurs bons outils peuvent faire l'affaire (quitte à ne pas tout activer de suite), je suis preneur. Je ne pense pas que mon projet puisse attirer de nombreuses foules (c'est plus unj projet à but didactique), mais on ne sait jamais … Celà dit, ce n'est pas encore fait, ce n'est juste qu'embryonaire, et si je galère trop je laisserai tomber (ou alors je le reporterai à plus tard).

      Si ton projet est naissant, les outils les plus importants sont de loin le gestionnaire de version, et, àmha, le gestionnaire de documentation. Un gestionnaire de documentation bien fait devrait te permettre de créer des pages html statiques comme des pages de manuel: c'est suffisant pour faire un site. Ces outils sont finalement assez rares.

      Je te conseille d'utiliser en priorité l'outil écrit dans le langage de programmation de ton projet: ce sera mieux intégré, et tu sauras le modifier si besoin.

      Style rdoc ? J'avais l'intention de creuser de ce côté.

      Pour la communauté, une adresse mail, indiquée dans le README, suffit largement au début, tant pour les rapports de bogues, les demandes d'informations, que les patchs.

      Je reçois déjà beaucoup de mail avec beaucoup de SPAM …. :( Je préfèrerais de suite passer à un outil un peu plus évolué (de toute façon je ne compte pas publier mon projet de suite, j'ai encore plein de choses à faire avant).

      Mettre en place tout cela, et faire des archives propres (avec readme, licence, changes, manuel) prend déjà beaucoup, beaucoup, beaucoup de temps.

      Je sais, c'est pour ça que je me renseigne à l'avance, je préfère partir sur de bonnes bases plutot que de devoir me poser ces questions plus tard.

      • [^] # Re: De la juste proportion

        Posté par (page perso) . Évalué à 4.

        Style rdoc ?

        Je pense à ce genre d'outils, oui, bien que je ne connaisse ni rdoc, ni ruby. L'essentiel étant de pouvoir produire html et pages man.

        Je reçois déjà beaucoup de mail avec beaucoup de SPAM … :(

        Je t'avoue que pour l'instant, l'adresse publique de mon projet est épargnée, ce qui me laisse croire que les spammeurs ont des moyens plus efficaces de collecter des adresses courriels que d'aller les chercher dans les archives des projets logiciels. Au pire, tu peux utiliser un de ces filtres antispam qui s'intègrent aux lecteurs de mail. Au pire du pire, tu peux indiquer dans le readme qu'il faut insérer tel ou tel mot clé dans le sujet du mail, et filtrer tes mails ainsi.

        Je sais, c'est pour ça que je me renseigne à l'avance, je préfère partir sur de bonnes bases plutot que de devoir me poser ces questions plus tard.

        J'ai eu la même réaction que toi. On m'a proposé les mêmes logiciels qu'à toi. Mais au final, la bonne solution, fut celle que je me suis construite sur mesure. Tout cela, ce n'est pas seulement la vitrine de notre projet, c'est aussi et surtout notre environnement de travail. Il faut qu'on ait du plaisir à travailler avec ces outils, et qu'on les maîtrise suffisamment pour pouvoir travailler correctement. Architecturer l'environnement de travail de son projet, ça fait partie du projet. Et je crois que c'est aussi un acte d'invention et de création.

        Pense par exemple que make (rake dans ton cas), peut servir à produire ton site, ta doc et tes archives, comme il sert à compiler les sources. Ah, et n'oublie pas de versionner la doc avec les sources.

        Bon courage !

Suivre le flux des commentaires

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