Sommaire
Il y a long entre le script qui fonctionne à la maison et le logiciel publié !
Cela est d'autant plus long pour moi que c'est par tâtonnement que j'avance. En effet, si les tutoriels apprenant à coder sont légions, ceux qui concernent la publication du code – et les inévitables étapes préalables à cette publication – sont plutôt rares, voire inexistants. Faute d'être capable d'écrire un tel tutoriel, je partage ici mon expérience, dans l'espoir que cela puisse faire gagner du temps à ceux qui, comme moi, se donnent pour but de publier pour la première fois un petit logiciel.
Ceux qui connaissent tout cela, peuvent directement passer à la partie « publication » qui, à défaut d'image, contient une requête.
Préparation
Mise en forme des sources
Le regard que l'on porte sur son code change radicalement lorsque l'on sait qu'il sera lu. Je constate que les bonne pratiques de programmation se perdent lorsqu'un script est modifié au moment même ou on veut s'en servir. Ainsi, je me suis vu modifier en profondeur le code source de mon logiciel, rien que pour le rendre présentable. Ce qu'il faut harmoniser est connu: noms de fonctions et de variables, contenu et place des commentaires, mise en page. Il est par contre moins souvent dit qu'il est plus efficace est de choisir un style formel et de l'appliquer sur l'ensemble des sources, que de faire cela à l'occasion. L'avantage, c'est que le style peut être décrit dans la documentation du projet, ce qui aidera les personnes désirant hacker le logiciel à se retrouver dans les sources, et cela harmonisera les contributions potentielles.
Ce travail stylistique est aussi l'occasion d'effectuer une révision générale du code et de ses algorythmes, afin de le rendre plus facile à comprendre et à maintenir.
Exceptions et configuration
La gestion des exceptions et les options de configuration sont des choses dont on se soucie peu lorsqu'on est le seul utilisateur d'un logiciel, mais qui sont indispensables pour un logiciel partagé.
Normalisation de l'interface
De même que le style du code doit être normalisé, de même, l'interface utilisateur doit être clarifiée. J'y travaille actuellement pour mon projet, et je m'aperçois que les enjeux sont importants, car une fois le logiciel publié, la liberté de modification sera limitée par l'exigence de rétro-compatibilité.
L'interface doit être cohérente, mémorisable, et respecter les usages. Comme ces trois conditions ne s'articulent pas toujours très bien, il faut faire des choix. Mieux vaut, à nouveau, se donner quelques principes et les appliquer rigoureusement. Ainsi, ces principes pourront être exposés dans la documentation du projet, et l'utilisateur sera plus à même de comprendre les choix ergonomiques. Ces principes guideront en outre les développements à venir, et assureront l'harmonie future de l'interface.
Documentation
Ceci étant fait, il est possible d'écrire l'indispensable manuel. Outre la liste des options et la description du format du fichier de configuration, une section consacrée au style formel utilisé pour le code (voyez la section « naming conventions » de groff_ms(7) à titre d'exemple), et les principes guidant les choix ergonomiques de l'interface y sont bienvenues.
La documentation ne concerne pas seulement le manuel, mais aussi les fichiers inclus dans l'archive: LICENCE, README, et pour les archives les plus soignées, CHANGES et TODO.
Publication
Ici, je me heurte à plusieurs difficultés…
Que devra contenir le site présentant mon petit projet ? Une page d'accueil, avec les dernières nouvelles (redondante avec la liste des modifications incluses dans l'archive), de la documentation (redondante avec les pages de manuel cette fois), une page de téléchargement. Si je veux faciliter les retours, un système de ticket serait utile. Et si je veux faciliter la collaboration, une liste de discussion, voire une forge collaborative.
Je pourrais décider de très bien faire, et déployer l'artillerie lourde: un wiki, un serveur de pages de manuel, une forge, un système de tickets. Mais pour moi qui ne connaît pas ces technologies, c'est un investissement énorme en temps pour apprendre à les utiliser, les mettre en place, et les maintenir. C'est donc totalement disproportionné pour mon projet. Je réfléchis donc à des solutions alternatives.
En un sens, j'ai d'ores et déjà le contenu sous la main: j'utilise un système de gestion de versions (RCS), la documentation est faite de pages de manuel et de README. Peut-être pourrai-je penser à cette bonne vieille méthode dite de la râche, qui via un script maison, prendrait tout ça en entrée, et ressortirait un site statique, que je n'aurais qu'à pousser par ftp. Méthode un peu moins conventionnelle, peut-être pourrais-je écrire toute ma documentation dans un format x (text2tag ou autre), et produire à partir de là un site d'un côté, manuels et README de l'autre. Peut-être, finalement, existe-t-il un outil créé spécialement pour ce genre de situation.
Je serais donc heureux d'avoir quelques retours sur les choix technologiques faits par ceux d'entre vous qui publient un petit projet logiciel.
# help2man
Posté par Denis Bernard (site web personnel) . Évalué à 4.
J'aime bien help2man, cet utilitaire qui génère un fichier man depuis le fichier d'aide. Il oblige, de fait, à produire un fichier d'aide bien structuré avec les mentions obligatoires (comme le numéro de version). Il facilite aussi les traductions.
[^] # Re: help2man
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'ai tendance à faire presque toute la doc utilisateur en POD… Il y a bien sur un wiki mais c'est en plus. J'intègre si possible la doc POD dans le fichier source (possible en Perl bien sur mais aussi avec bash, Fortran…) et une petite règle dans un Makefile me mouline tout cela en des fichiers man et même temps que la compilation !
Je trouve que pour beaucoup de chose, la doc au format man est bien pratique. C'est souvent bien pratique d'avoir tout sur sa machine et qui ne prennent pas 3Go de disque ni dix milliard de cycles CPU lors de l'utilisation !
Exemple à ne pas suivre, les dernières version du compilateur intel prennent plus de 2Go d'espace disque juste pour pouvoir faire icc ou ifort… Tout cela car il y a un bordel de doc et de java complètement inutile mais placé dans une arborescence digne d'Adobe ;-)
# Une petite page
Posté par Colin Leroy (site web personnel) . Évalué à 3.
Pour mes petits projets, je mets tout sur Sourceforge (un SVN dont la révision ne dépassera pas les 100 avant des années, un tarball tous les ans à peu près, et une toute petite page html de base pour faire joli.
Y'a les trackers, mais comme c'est du tout petit projet, personne ne les utilise ou presque :)
Ça me permet juste d'être content si quelqu'un trouve le truc utile !
# pistes
Posté par BAud (site web personnel) . Évalué à 5.
Tu les indiques (bugtracker, README/LICENSE, pages de man…), tu retrouveras ces points et quelques autres sur :
http://faq.tuxfamily.org/CommunicationLibre/Fr
http://faq.tuxfamily.org/CommunicationLibreSoftware/Fr
ça peut être complété bien sûr :-)
[^] # Re: pistes
Posté par neil . Évalué à 3.
Il y a aussi
info standards, mais c'est vraiment pour les barbus de la FSF.# Voyage dans le temps
Posté par Sufflope (site web personnel) . Évalué à 3.
RCS, seriously ? Même question pour FTP.
J'allais proposer de regarder du côté des forges modernes qui te gèrent tout ça (tickets, exploration du code, page d'accueil, wiki, etc etc) et proposent même des hébergements gratuits comme indefero, mais j'ai l'impression que l'hébergement gratuit pour les projets publics a disparu :(
[^] # Re: Voyage dans le temps
Posté par Dorian . Évalué à 5. Dernière modification le 05 mai 2012 à 21:15.
Sinon il y a GitHub :
- Page de projet générée (projet.github.com)
- Gestion de tickets
- Wiki
- Téléchargement
- Versions du code (via Git)
- … etc
Tout est optionnel (sauf le code :D)
(Il y a des équivalents libres (Gitorious, etc…) mais je les connais mal pour en parler)
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Voyage dans le temps
Posté par BAud (site web personnel) . Évalué à 6.
comment cela ? il y a encore :
http://gna.org
http://savannah.gnu.org/
http://tuxfamily.org
et maintenant http://gitorious.org
en plus des sourceforge… (et même berlios)
[^] # Re: Voyage dans le temps
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
Et http://chiselapp.com/ pour le DVCS Fossil qui intègre gestion de source avec versions, bug tracker, wiki, site web, documentation, gestion des droits développeurs/admins/etc., bref que du bonheur.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Voyage dans le temps
Posté par Sufflope (site web personnel) . Évalué à 2.
Je parlais des comptes gratuits indefero (mais c'est vrai que c'était pas clair). Quant à gitorious pour moi c'est comme github (et même pire), très bien pour le dépôt mais ne mérite pas le nom de forge (système de tickets risible entre autre).
[^] # Re: Voyage dans le temps
Posté par BAud (site web personnel) . Évalué à 2.
oui, ce n'était pas clair… quel est le souci ?
peux-tu préciser et notamment indiquer les améliorations que tu n'auras (je n'en doute pas) manqué d'indiquer sur https://issues.gitorious.org/projects/gitorious/issues ?
Tu auras bien sûr lu https://issues.gitorious.org/projects/gitorious au préalable ;-)
[^] # Re: Voyage dans le temps
Posté par Sufflope (site web personnel) . Évalué à 3.
Ché pas, regarder ce qui se fait chez les autres forges depuis 15 ans ? (roadmap, prio, assignations, et j'en passe). C'est quand même pas à moi d'au moins faire un benchmark de l'existant.
github (et par ricochet gitorious) ont fait le choix de faire du cool sur l'aspect git (assez brillamment il faut le dire) et proposer un truc minimal (voire inexistant) pour le reste, parce quand dans l'optique cool de la partouze du fork, 90% des projets sont mort-nés donc osef d'avoir du suivi à plus long terme qu'un mois.
Résultat les gens qui ont des gros projets à long terme utilisent github avec des hooks vers une vraie forge. Ou directement une vraie forge.
[^] # Re: Voyage dans le temps
Posté par Sygne (site web personnel) . Évalué à 3.
J'ai
travaillébidouillé sur deux forges modernes: mercurial et fossil.J'ai trouvé Mercurial trop complexe pour le temps que j'étais prêt à lui consacrer. Même la chose la plus simple (pousser une modification) me semblait inutilement compliqué. Il était couplé avec Redmine pour l'affichage sur le net, et j'ai bien vu que la maintenance de l'ensemble était assez lourde.
Fossil me semble plus simple et accessible. Je l'ai justement essayé pour mon projet personnel, car il intègre un wiki et un système de tickets. Mais ça m'a semblé disproportionné pour mon minuscule projet qui n'aura jamais qu'un contributeur. Les forges servent à gérer collaborativement le code source, et toute leur interface – tant du point de vue du développeur que du point de vue du visiteur du site – mettent en avant cette fonctionnalité.
Ce dont j'ai besoin, c'est surtout d'une interface dédiée à la publication du projet. Ce ne sont pas tant les sources que la documentation que je veux mettre en avant. À la limite, la « timeline » n'est rien de plus que de la documentation dans l'optique d'un petit projet. Or, les forges ne sont pas ergonomiques pour la documentation.
À titre d'exemple, le wiki de fossil utilise l'html comme syntaxe et la page d'accueil du wiki n'est pas configurable. Fossil ne sait pas transformer une page de manuel en html, il faut donc dupliquer l'information. Bref, il faut s'adapter à l'interface plutôt qu'utiliser une interface adaptée à ses besoins. Et à ma connaissance, fossil est la seule forge qui permette de documenter son projet.
Si c'est la seule solution, j'utiliserai fossil, mais à reculons.
[^] # Re: Voyage dans le temps
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Via le menu Admin => configuration, tu peux changer la page d'accueil du projet et choisir n'importe quelle page du wiki.
Via le menu Admin => Header, tu peux éditer la liste des liens et donc remplacer le lien la page d'accueil du wiki par un lien vers une autre page.
Tu dois pouvoir faire ça en t'inspirant de http://kott.fm/tomek/2011/06/23/highlighting-code-diffs-in-fossils-ui/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Voyage dans le temps
Posté par Sygne (site web personnel) . Évalué à 3.
Ah oui, bien vu, je n'avais pas pensé à ça.
L'autre solution sur laquelle j'ai planché (et pas mal avancé) consistait à adapter le fichier wikiformat.c et à recompiler fossil. Je ne connais pas javascript, et l'idée de faire du navigateur un interpréteur de script ne me plaît pas, mais c'est probablement une solution plus simple.
[^] # Re: Voyage dans le temps
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
http://fossil-scm.org … un binaire compilé statique et tu as ta forge en quelques secondes. J'ai essayer sur un hébergement mutualisé : le binaire dans cgi-bin, deux lignes dans un fichier texte et voilà. Et comme les pages de wiki ou les tickets sont versionnés comme le code, tu as tout en local et sur le net.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Voyage dans le temps
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Quatres autres avantages de fossil:
il permet de faire facilement de l'autohébergement à tolérance de panne.
(Par exemple j'héberge mes projets sur http://devnewton.bci.im et si mon serveur tombe, je fais redirection DNS vers http://chiselapp.com/user/devnewton/)
un dépôt est un simple fichier, donc très facile à sauvegarder ou à transporter sur une clef USB.
les échanges avec un dépôt distant se font par http(s), ça passe donc les proxys nazis.
on peut éditer le wiki et utiliser le bug tracker sans avoir accès à internet.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Voyage dans le temps
Posté par oinkoink_daotter . Évalué à 0.
Toi, t'as jamais vu un vrai proxy nazi …
[^] # Re: Voyage dans le temps
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Disons un proxy ump.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Voyage dans le temps
Posté par oinkoink_daotter . Évalué à 0.
C'est un proxy qui ventile beaucoup, troué de partout et qui fait beaucoup de bruit ? ^
# Sphinx ?
Posté par mrr . Évalué à 6.
Salut,
Pour la doc, peut être que tu devrais jeter un coup d'oeuil à Sphinx ?
Ça génère des sites de doc pas trop moches, des pages de man et des ebooks à partir de sources en reStructuredText, il y a aussi un service en ligne …
Par contre, si la doc de ton outil est vraiement petite et tiens dans un
README, tu devrais peut-être te tourner vers une interface Web à un DCVS qui présenterai le tout de façon ergonomique (genre Github ou Gitorious) …Bonne chance pour ton projet en tout cas :-)
Envoyé depuis ma Debian avec Firefox
[^] # Re: Sphinx ?
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Dans le cas de github, tu peux même générer une page web assez jolie à partir du README. Cf https://github.com/blog/1081-instantly-beautiful-project-pages
[^] # Re: Sphinx ?
Posté par Sygne (site web personnel) . Évalué à 2.
La documentation de mon projet est destinée à être conséquente. De fait, pendant un temps, plutôt que de chercher une forge, je cherchais un système de publication de documentation. J'avais trouvé sphinx, mais aussi manserver, et j'ai jeté un coup d'œil aux moteurs de wiki.
C'est là qu'est apparu mon problème: pour publier de la documentation proprement, mieux vaut utiliser les logiciels qui conviennent. Pour publier les sources, ce sont d'autres logiciels.
Ainsi, non seulement j'hésite sur le choix de la technologie à utiliser, mais en plus, je ne suis pas certain que ces technologies me fassent gagner du temps.
[^] # Re: Sphinx ?
Posté par Spack . Évalué à 3. Dernière modification le 06 mai 2012 à 13:30.
Il y a aussi Publican utilisé entre autres par Red Hat et Fedora. Il prend du Docbook en entré et permet de générer un certain nombre de formats.
[^] # Re: Sphinx ?
Posté par JGO . Évalué à 2. Dernière modification le 06 mai 2012 à 20:12.
Ça a l'air très bien, mais l'installation est mal documentée (un comble hein). Le manuel d'installation ne contient que des informations génériques sans intérêt pour savoir comment mettre à jour sa Debian et comment il faut double-cliquer sur un exécutable (pas moins de 8 étapes numérotées) pour installer sous windows.
Mais pas d'informations sur la compilation depuis les sources. Le fichier Readme présent dans les sources est largement incomplet (nombreuses lignes TODO qui indiquent ce qu'il manque encore à expliquer) et la commande « Perl Build.PL » qui est indiquée ne marche pas (Can't locate File/pushd.pm in @INC ………).
[^] # Re: Sphinx ?
Posté par JGO . Évalué à 2. Dernière modification le 07 mai 2012 à 10:01.
Pourquoi ladite commande ne marche pas : ça a à voir avec la ligne "TODO deps" dans le README. J'ai déjà trouvé qu'il lui faut les modules File-pushd, XML-Simple, TreeBuilder, et ça continue.
# Fossil
Posté par Guillaume D. . Évalué à 6.
Fossil est un DCVS mais aussi un wiki, un outil de gestion de ticket et une interface Web (et son serveur) dans un seul exécutable. ( aussi installable sur un serveur ).
le site : http://www.fossil-scm.org/fossil/doc/trunk/www/index.wiki
# A la google
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
Pour les petits projets, comme gocoincoin
je vais chez google et je mets en place un google group
# un page web
Posté par Troy McClure (site web personnel) . Évalué à 10.
Si c'est vraiment un petit projet, alors fais lui une page web, fais la bien et laisse tomber le reste. Perso je m'interesse toujours plus a un projet qui a une vraie page d'acceuil , un truc pas trop moche dont on sent que le dev l'a un peu travaillée et pas un truc pondu a la va-vite. Avec des screenshot, des exemples, des comparaisons avec les logiciels similaires bref un petit argumentaire pour convaincre le barbu de passage qu'il est tombé au bon endroit
[^] # Re: un page web
Posté par Anthony Jaguenaud . Évalué à 6.
C’est compliqué d’être bon technicien et bon markéteu. Moi c’est l’inverse, malgré l’aversion d’un site un peu juste, je cherche les infos. Les trucs trop beau me rendent méfiant.
[^] # Re: un page web
Posté par Octabrain . Évalué à 5. Dernière modification le 06 mai 2012 à 14:44.
Bof, quelqu'un qui lache les sources avec évenutellement une petite manpage, je trouve ça pas assez, surtout s'il faut télécharger/extraire une tarball pour lire la doc et voir que ça nous intéresse pas (d'ailleurs c'est bien con que les navigateurs forcent à télécharger un .c pour le lire alors que c'est du text/plain).
Si au contraire il y a le minimum qui montre si c'est intéressant ou pas (screenshots (si c'est graphique), une liste de fonctions principales, quelques exemples de ligne de commande (si ça s'utilise comme ça) avec juste une phrase d'explication pour chacune), et ça devient acceptable de fouiller un peu les sources pour savoir comment ça s'utilise vraiment, mais pour ça il faut qu'on se soit d'abord rendu compte que ça pouvait être bien.
[^] # Re: un page web
Posté par Troy McClure (site web personnel) . Évalué à 6.
méfiant de quoi ? je ne vois pas ce qu'il y a de suspect a passer un peu de temps a faire une belle page web
[^] # Re: un page web
Posté par daimrod . Évalué à -2.
C'est du temps qui aurait pu être utilisé pour corriger des bugs, peaufiner la documentation ou améliorer le code.
[^] # Re: un page web
Posté par Troy McClure (site web personnel) . Évalué à 8.
ah ouais alors qu'un mec qui se contente de balancer un tar.gz comme on descend les poubelles, tu te dis celui "c'est un bon il n'a pas perdu de temps a faire une page web pour presenter son soft c'est sûr qu'il a tout misé sur la doc et le debuggage".
[^] # Re: un page web
Posté par jigso . Évalué à 2.
Non, non, pas de doc ni de commentaires, on en chie à l'écrire, les autres doivent en chier à le lire.
[^] # Re: un page web
Posté par daimrod . Évalué à 1.
J'ai parlé d'améliorer la documentation et le code (dans le code je pense aussi au système de build utilisé), et je préfère une bonne doc à un joli design. Et puis si la documentation est dans un format correct (org-mode, markdown, …) on peut façon facilement exporter le tout vers du html. Par exemple le rendu de github est plutôt sympa.
[^] # Re: un page web
Posté par JGO . Évalué à 2.
Personnellement je ne suis pas web designer, mais alors pas du tout. Je sais faire <h1>Titre</h1><p>Contenu</p> depuis environ 1993 (enfin en 93 on utilisait <br>), j'ai bien essayé d'apprendre CSS entre-temps mais c'est juste pas mon truc, j'ai pas la fibre artistique. Je veux bien documenter un petit projet au format texte brut (restructured text, markdown…), le passer dans une moulinette avec le style par défaut et publier un contenu statique. Du coup tu ne t'intéresseras pas au code libre que je pourrais publier ? Parce que le site n'en met pas plein les yeux ?
[^] # Re: un page web
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 7.
En même temps dans l'idée de juste faire une petite page mais de la faire bien, je suis pas persuadée que le but ce soit d'avoir un truc qui «en met plein les yeux».
En tout cas, je sais que perso j'aime bien les petits projets où y'a l'effort de faire une présentation du logiciel qui soit pas juste le README, un lien vers un fichier de téléchargement accessible et simple à installer et pas «récupère la dernière version par git/svn/…»,`où y'a quelques screenshots (pour les applis graphiques), une liste rapide des fonctionnalités et des manques (si c'est en développement) du logiciel. S'il y a une CSS basique ou qu'il y en a pas c'est pas le problème, je crois que ce qui va me donner envie c'est qu'il y ait une vraie ''présentation'' du logiciel (je pense que c'est un peu différent de la documentation).
# Documentation : en dehors des outils
Posté par Victor . Évalué à 3.
Salut,
En lisant ton journal, je remarque des préoccupations qui sont très souvent traités par la recherche en architecture logicielles et leur documentation.
Pour des idées, infos et exemples, il y a le wiki du SEI, un organisme de recherche très connu dans le domaine :
https://wiki.sei.cmu.edu/sad/index.php/Main_Page
En fait ce wiki accompagne un bouquin qui est pour moi une bible sur la documentation du logiciel.
Sinon, d'une façon générale, les problèmes que tu poses sur l'organisation du code sont ceux auxquelles les architectures logicielles tentent de répondre.
# Keep it...
Posté par Ignatz Ledebur . Évalué à 6.
En tant qu'auteur de nano-projets, je te conseillerais de rester le plus simple possible. Pour mon premier, j'avais vu "grand" avec un site dédié (présentation, changelog, FAQ, page de téléchargement, le tout en HTML vaguement mouliné), branches stable/devel et listes de diffusion devel/annonces. Ça n'a jamais servi à rien, à part à alourdir la gestion du bouzin. C'est pour ça que très vite j'ai adopté le modèle "un projet, une branche, une page, (jawohl!)" et ai par la suite fini par grouper tous mes projets sur un seul site (au passage, merci à l'équipe de tuxfam. pour avoir toléré mes tergiversations :). J'ai même au bout du compte abandonné les contrôleurs de version. En cinq ans, je ne me souviens effet pas avoir eu besoin de revenir en arrière. D'ailleurs, même si ça se présentait, en tant qu'auteur unique je ne vois pas ce qui serait insurmontable (de fait, tout reste dans mes compétences, en plus hein! ça me fait la couenne, j'ai qu'à savoir ce que je veux), et puis il y a toujours le rustique mais efficace cpold.
Aujourd'hui je génère mon site et mes manuels à partir d'une moulinette perso qui prend des sources type Markdown (jette un œil sur l'implémentation initiale de cette syntaxe, tu verras que ce n'est pas très sorcier de bricoler quelque chose autour, y compris vers groff_man, qui est finalement assez simple). Je pousse ensuite tout ça en statique via un script de miroir basé sur lftp, et roule (autre chose appréciable chez tuxfam., tu peux gérer ton site alapapa®).
D'une manière générale, attends que les besoins soient là avant d'y répondre, tout anticiper étant le meilleur moyen de se retrouver avec une montagne accouchant d'une souris (ou plutôt l'inverse : un truc long et douloureux qui fait bien chier). Fais donc avant tout les choses pour toi, au plus simple comme ça t'arrange, et reste à l'écoute des éventuels retours pour décider des changements à apporter.
Sauf que l'ampleur des changements, tu ne peux jamais la prévoir. Pour le moment, j'ai trouvé deux parades :
Voilà, c'était mon petit retour d'expérience à deux balles… :)
[^] # Re: Keep it...
Posté par Octabrain . Évalué à 4.
Ouf merci, je n'osais avouer à personne que je trouvais cpold bien plus simple pour des micro-projets que de se forcer à gérer proprement des versions et tout le toutim, de peur de passer pour un fou. Ça me rassure de voir qu'il y a au moins une autre personne au monde qui pense aussi ça :)
[^] # Re: Keep it...
Posté par Sygne (site web personnel) . Évalué à 5.
Essaye RCS, c'est une sorte de cpold: il te fait une copie de ton fichier dans le répertoire dudit fichier (ou dans le sous répertoire RCS s'il existe), et il y archive tes modifications.
Pour un usage basique, on n'utilise que trois commandes :
- ci -l monfichier : archive de la version courante (check-in).
- co -l monfichier : écrase la version courante par la version archivée (check-out).
- rcsdiff monfichier : diff entre la version courante et celle qui est archivée.
Bref, que du bonheur.
[^] # Re: Keep it...
Posté par Ignatz Ledebur . Évalué à 1.
Non Jeff, t'es pas tout seul… Enfin, j'essaie quand même de me tenir à une discipline : 1 cpold = 1 fonctionnalité majeure précise, et chaque version du logiciel ne doit pas avoir plus de un ou deux changements majeurs. Comme ça, une fois que c'est bouclé, sauf découverte d'un bug critique (rare) dans la version publique, je m'installe une rc privée sur mon système que j'utilise quelques semaines avant publication. Ça permet d'être sûr que tout tient à peu près debout avant de livrer et évite au mieux les livraisons-colmatages catastrophes pour les utilisateurs. :)
[^] # Re: Keep it...
Posté par BAud (site web personnel) . Évalué à 3.
oh bah de rien, la plateforme est là pour être utilisée au mieux, quels que soient les besoins.
Si tu as des recommandations ou des cas d'utilisation spécifiques, j'ai déjà donné l'url de la faq qui est éditable par tous les utilisateurs :-)
[^] # Re: Keep it...
Posté par Ignatz Ledebur . Évalué à 1.
Ah bah quand même, faut le dire de temps en temps. Perso, je vous fais de la pub dès que je peux (en insistant bien pour que les gens indiquent la licence de leur projet en 4x3 dans leur requête, histoire de pas se faire doucher au premier contact ! ;)
[^] # Re: Keep it...
Posté par Sygne (site web personnel) . Évalué à 4.
Merci pour ton riche retour d'expérience et tes précieux conseils.
J'ai l'impression que c'est finalement la solution la plus simple et la plus souple pour les petits projets. Je crois que je vais m'orienter vers une solution de ce genre.
[^] # Re: Keep it...
Posté par Ignatz Ledebur . Évalué à 1.
De rien, tant mieux si ça peut servir. :)
À noter que c'est aussi une bonne idée de te référencer sur fresh… euh freecode et d'y annoncer chaque release pour donner de la visibilité à ton projet. Comme c'est un index pompé par quasiment tous les autres, tu te retrouves très vite un peu partout.
J'ai également oublié un conseil sur la procédure d'installation : passe par un configure/Makefile, en copiant l'interface des autotools même si tout est maison (en particulier le support de la variable d'installation DESTDIR). Ça simplifiera beaucoup le boulot des éventuels empaqueteurs (bon, vu la teneur de ton journal, tu y as sûrement déjà pensé).
[^] # Re: Keep it...
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Pour générer des pages de man à partir de markdown, je me permets de citer ronn et md2man.
# Framabook - Produire du logiciel libre
Posté par Nic0 (site web personnel) . Évalué à 5.
Salut,
Ton journal me fait pensé un peu à un livre intéressant, peut être orienté pour plus gros projets, mais le livre fourmille de conseils et anecdotes concrètes, plein de bon sens, et applicable également pour de petits projets. Il est disponible librement chez Framabook, sous le titre de Produire du logiciel libre.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.