Le projet a commencé comme un simple suivi de bugs, le parcours d'un dépôt git arrivant très rapidement. Aujourd'hui, toutes les fonctionnalités du GoogleCode de l'époque ont été implémentées, il manque maintenant la revue de code pour être l'égal de ce dernier.
« C'est un grand plaisir de développer ce logiciel. » précise Loïc. « J'ai particulièrement été étonné par la qualité des remarques ici quand j'ai informé des mises à jours (oui, l'installation reste difficile) et aussi des personnes venues contribuer. Le support de Subversion et de Mercurial a été fait par des contributeurs. La dernière version inclut donc le support de Mercurial et un wiki pour la documentation. »
InDefero utilise Pluf, un framework PHP5 ayant l'esprit et la forme de Django. C'est ce framework qui a permis le développement très rapide d'InDefero.
Donc encore merci aux contributeurs/utilisateurs pour vos contributions et remarques, continuez ! Et si vous êtes nouveaux, venez sur l'IRC, canal #indefero des serveurs freenode, Loïc est presque tout le temps présent pour donner un coup de main, particulièrement pour l'installation.
NdM : Merci à Loïc, pour son journal à l'origine de cette dépêche. En 4 mois de développement, voici la liste des fonctionnalités implémentées :
- Projets multiples avec une installation.
- Une page d'accueil pour chaque projet.
- 3 modules : suivi de bug, parcours de dépôt (git, subversion, mercurial) et wiki.
- La configuration du dépôt est indépendante pour chaque projet, vous pouvez avoir l'un utilisant subversion et l'autre git.
- Gestion de droits d'accès sur chacun des modules et ceci par projet (utilisateurs anonymes, authentifiés, membres du projet et administrateurs du projet). Vous pouvez donner accès au code uniquement aux membres par exemple.
- Projets privés, pratique pour votre todo list ou les projets internes de votre entreprise. Ainsi vous n'avez qu'une seule forge à gérer.
- Une ligne du temps qui déroule l'activité du projet.
- Utilisation importante des étiquettes pour classer les tickets, téléchargements ou pages de la documentation.
- Un moteur de recherches.
- Localisé en Anglais et Français.
- Étiquettes pour les tickets.
- Commentaires sur les tickets avec liens entre les tickets et les commits réalisés automatiquement.
- Liste de tickets par étiquette ou statut.
- Liste personnelle des tickets soumis ou assignés.
- Pourcentage des tickets fermés pour chaque étiquette permettant de réaliser une étiquette « jalon (milestone) » et ainsi voir le travail restant à effectuer avant la sortie.
- Suivi de certains tickets avec une étoile pour avoir la notification de l'évolution du ticket via courriel.
- Notifications par courriel.
- Fichiers attachés aux tickets pour des patchs ou autre.
- Moteur de recherches (classement par score avec lemmatisation (stemming) pour de meilleurs résultats).
- Une API pour soumettre des tickets et lister les tickets (REST et réponse JSON).
- Support de git, subversion et mercurial (peut-être bientôt bazaar).
- Changelog du code par branche.
- Diff d'un commit avec une jolie visualisation.
- Téléchargement de chaque fichier à n'importe quel révision/commit.
- Téléchargement d'une archive zip de tout le dépôt à n'importe quel commit/révision.
- Visualisation du code en ligne avec coloration syntaxique.
- Liens des messages de commit vers les tickets.
L'installation reste un peu difficile, il n'y a pas un script qui fait tout, il faut avoir accès à PHP en ligne de commande et comprendre un peu les chemins d'inclusion de PHP pour avoir le code du framework Pluf (dont il faut utiliser la dernière version) dans l'include_path de PHP.
Aller plus loin
- Projet Indefero (27 clics)
- Téléchargement d'InDefero 0.4.0 (3 clics)
- Google Code (2 clics)
- Capture d'écran (6 clics)
- Capture d'écran « historique » (2 clics)
- Journal à l'origine de la dépêche (3 clics)
# Très bon ça, le support Mercurial :)
Posté par Temsa (site web personnel) . Évalué à 4.
Manque plus que des outils de pull/clone façon bitbucket et ça deviendra vraiment sympa !
[^] # Re: Très bon ça, le support Mercurial :)
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 3.
Merci !
[^] # Re: Très bon ça, le support Mercurial :)
Posté par Temsa (site web personnel) . Évalué à 2.
Tu peux en un clin d'oeil, en temps que visiteur authentifié(mainteneur, developpeur, ou simple visiteur), faire un fork du projet et l'heberger dans tes propres projets, tout en prevenant les membres du projets d'origine.
Ceci permet de se constituer sa propre "branche", pour faire ses essais, ses modifications, puis les reproposer au mainteneur une fois stable, en lui faisant une pull request.
Quoi de mieux pour l'open source ? Il devient très simple de maintenir un patch sur un projet, ou d'implémenter tranquillement sa nouvelle idée et la proposer une fois satisfait. Si la modification satisfait au règle du projet, il deviendra alors simple d'intégrer et les modifications et le/les developeurs dans le coeur du projet principal.
Ceci favorise donc grandement la méritocratie, en allant bien plus loin qu'un simple VCS comme SVN, c'est la liberté au sens propre, et ça gomme beaucoup des aspects qui empêchent parfois le libre d'avancer (imaginez que XFree86 ai été géré via ça, il n'y aurait peut être pas eut besoin d'une rebellion et d'un Xorg, ou au contraire il y aurait plusieurs Xorg like actuellement, basés partiellement sur les même sources, et mergeables à souhait.
Même en entreprise, ceci est utile, car ca simplifie et générise les process pour dériver le travail d'un projet.
Bref, des boutons certes pas indispensables, mais bien pratique ;)
[^] # Re: Très bon ça, le support Mercurial :)
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 2.
Une demande de pull, c'est en fait une demande de revue de code pre commit. On pourrait donc très bien imaginer un système pour facilement pousser une demande d'un projet vers un autre. L'intérêt est aussi que je peux faire cela avec n'importe quel backend, git, mercurial ou subversion.
Merci !
# Retours sur ce type d'application
Posté par Julien CARTIGNY (site web personnel) . Évalué à 2.
[^] # Re: Retours sur ce type d'application
Posté par CrEv (site web personnel) . Évalué à 5.
C'est ce qu'on utilise maintenant dans ma boite.
Il est multi-projet, assez rapide, assez simple à installer (ds un journal sur le sujet je crois que j'avais collé un petit script pour le faire sur une ubuntu server).
Les droits sont pas trop mal gérés, mais j'ai pas encore réussi à le coupler avec un ldap comme je voudrais (en fait un AD...)
La gestion svn est sympa.
Pour ce qui est des migrations (important car on avait déjà un bug tracker) j'ai passé une journée dessus, en modifiant les scripts de migration existant pour mantis et trac je crois, ça se fait facilement si on connait ruby
Par contre, pas toujours facile pour gérer par exemple les mêmes versions entre des sous projets, pour gérer des champs perso basés sur des champs existant, etc
Mais pour le moment c'est ce que j'ai trouvé de mieux (quoique un projet comme InDefero semble sympa aussi)
# Django ?
Posté par Bozo_le_clown . Évalué à 4.
Extrait de son journal:
Par contre, je persiste même si cela fait rire certains, c'est du code PHP propre[6]. Cela montre qu'on peut développer une application élégante, rapide et puissante en PHP en n'ayant pas honte du code. Utilisateur intensif de Django[7], j'ai pu voir du code Django impossible à maintenir et à comprendre aussi bien que du merveilleux. On trouve de tout partout, mais c'est vrai qu'il y a beaucoup de mauvais PHP...
Loic, Tu évoques le fait que tu connais bien Django et tu soulignes le fait que PHP est limité. Pourquoi ne pas avoir choisi Django, d'autant qu'un issue tracker potable en Django ca manque, il me semble.
[^] # Re: Django ?
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 10.
Deux raisons m'ont poussées à coder cela en PHP :
- La première et la plus importante, la disponibilité de PHP pour presque tout le monde, partout, facilement. Je souhaite donner la possibilité à tous d'utiliser InDefero facilement sur la majorité des hébergements. PHP est pour cela merveilleux. (ok, il manque un petit script d'installation automatique pour InDefero, mais cela va venir). Un logiciel libre a besoin d'une communauté d'utilisateur, j'ai donc choisi la technologie qui offre accès à la plus grande communauté/base d'utilisateurs.
- Le seconde, bien égoïste, étant développeur de Pluf, c'était l'occasion de montrer qu'on peut facilement faire du code propre et efficace, le tout rapidement, avec ce framework. Rien de tel pour faire la pub d'un framework qu'une "killer app" que tout le monde veut installer.
- La troisième, pas vraiment bonne donc à ne pas vraiment compter, les limitations du système de gabarit de Django avec l'impossibilité de mettre des if/then/else un peu compliqués dedans (on peut changer ça, mais ce n'est plus standard pour les templates venant d'autres applications).
Par rapport à ta remarque sur les limitations de PHP, je dirais qu'aujourd'hui on peut tout faire correctement et facilement avec n'importe quel langage orienté web ou ayant un framework de qualité. Pour ce type d'application, PHP, Ruby, Erlang ou Python c'est grosso-modo la même chose, plus une question de goût et surtout d'efficacité et de connaissance des outils par les développeurs.
En espérant avoir répondu à tes questions.
loïc
[^] # Re: Django ?
Posté par Bozo_le_clown . Évalué à 3.
Je me permets de te poser une question sur les fonctionnalités de ton projet.
Ce qui manque sur tous les outils libres de ce type est à mon sens la gestion correcte des sous-tâches.
Or dans le cadre d'un projet en cours de développement (je ne parle pas de la maintenance) on a rarement une correspondance 1 pour 1 entre une activité et un ticket. D'où l'importance de pouvoir créer des sous-tâche rattachées à une tâche principale.
As-tu prévu une évolution de ce type ?
[^] # Re: Django ?
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 2.
http://projects.ceondo.com/p/indefero/issues/55/ (regarde les commentaires 6 et 7)
Par contre, si c'est un travail plus important, le plus simple et le plus élégant est de créer une étiquette "Tâche:Fonctionnalité-Truc" et d'associer cette étiquette au tickets correspondants. C'est à mon avis la méthode la plus simple et surtout, cela permet de garder l'interface d'ajout d'un ticket la plus simple possible. La devise d'InDefero est "beautiful simplicity" soit "belle simplicité".
[^] # Re: Django ?
Posté par Bozo_le_clown . Évalué à 4.
car il n'est pas référencé dans la news
http://www.pluf.org/
[^] # Re: Django ?
Posté par Corto . Évalué à 2.
http://fr.wikipedia.org/wiki/Liste_de_frameworks_PHP
Je sais que quand j'ai à me renseigner sur une techno ou autre, je commence souvent par la...
[^] # Re: Django ?
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 4.
[^] # Re: Django ?
Posté par Bozo_le_clown . Évalué à 5.
Et quand tu dois en choisir un, tu fais pluf pluf ?
Oui .... euh d'accord, c'est par là => [ ]
[^] # Re: Django ?
Posté par Corto . Évalué à 1.
J'avais présélectionné Zend, Jelix et Castor... et ton framework me semble être un peu dans le même ligné...
Quels sont les avantages des uns par rapports aux autres ? Si quelqu'un a un retour d'expérience, ca m'intéresse.
Merci,
Corto
[^] # Re: Django ?
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 3.
Le mieux, si tu as le temps, c'est de prendre les 3 qui te semblent les plus adaptées à tes besoins et à ta manière de penser. Ensuite, tu démarres ton projet sur chacun des frameworks, éventuellement en parallèle. Cela va vite te permettre de sentir les différences d'approche. Car au final, un framework permet juste d'avoir un cadre de développement pour faire une bonne séparation de la logique, les données et la présentation[1].
Si il y a 50 frameworks différents, c'est bien parce que c'est simple de développer un framework en PHP, et surtout, chacun conçoit ce truc tout simple de prendre une requête et retourner un bout de texte d'une manière différente. Donc essaye, et si par hasard tu trouves que Pluf te convient, n'hésite pas à demander de l'aide, je suis là pour ça.
[1]: http://pluf.org/doc/understanding-pluf.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.