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 Framasky (site web personnel) . É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).
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Github.
Posté par pralines . É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 Framasky (site web personnel) . Évalué à 1. Dernière modification le 27 juin 2013 à 00:13.
Moui m'enfin bon.
Ok, github, saymal, mais :
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Github.
Posté par Ymage . Évalué à 3.
Avec ta logique, on peut en dire autant de tous les outils Google alors :-)
Et pourtant …
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: Github.
Posté par Framasky (site web personnel) . Évalué à 1.
Bah, je suis pas sûr que tu puisse faire le site du projet directement avec google code. Alors que Github, si.
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 ?
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
# Taille de la communauté
Posté par davandg . É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 totof2000 . É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 Elwood_Blues . Évalué à 1.
Si tu ne veux pas utiliser un service en ligne, tu peux utiliser Redmine aussi…
[^] # Re: Redmine
Posté par bibitte . É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 totof2000 . É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 xcomcmdr . Évalué à 1.
Le fork ChiliProject est pas mal non plus.
https://www.chiliproject.org/projects/chiliproject/wiki/Why_Fork
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Redmine
Posté par pralines . É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 devnewton 🍺 (site web personnel) . Évalué à 3.
http://fossil-scm.org
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# De la juste proportion
Posté par Sygne (site web personnel) . É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 totof2000 . Évalué à 2.
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).
Style rdoc ? J'avais l'intention de creuser de ce côté.
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).
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 Sygne (site web personnel) . Évalué à 4.
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 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.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.