Articles précédents : Développeur
- [26] Étoilé 0.4 de sortie
- [39] Phoronix souhaite savoir comment vous utilisez Xorg
- [21] OpenExpert est à la recherche de contributeurs
- [159] Campagne de dons pour le compilateur PCC
- [8] Sortie de Merb 1.0
- [34] Webinaire sur la forge libre Codendi
- [23] Pré-version de démonstration de QtCreator (dit Greenhouse)
- [1] CodeCamp OLPCFrance le 15 nov. à LaCantine (Paris)
- [0] Trophées du Libre 2009
- [42] Gestion des puces Broadcom 63xx dans OpenWrt
Liens connexes
- Projet Indefero (986 hits)
- Téléchargement d'InDefero 0.4.0 (115 hits)
- Google Code (216 hits)
- Capture d'écran (696 hits)
- Capture d'écran « historique » (297 hits)
- Journal à l'origine de la dépêche (279 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : InDefero, Wiki et support de Mercurial dans la version 0.4.0
Posté par Florent Zara (Jabber id, page perso, ). Modéré le 24 novembre 2008.
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.
![[fr]](../../../images/fr.png)
Projet Indefero (986 hits)-
Téléchargement d'InDefero 0.4.0 (115 hits)
![[en]](../../../images/en.png)
Google Code (216 hits)-
Capture d'écran (696 hits)
-
Capture d'écran « historique » (297 hits)
-
Journal à l'origine de la dépêche (279 hits)
> Lire la suite (16 commentaires, moyenne: 3,5). [dépêche : 2935 caractères]
- 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.
Très bon ça, le support Mercurial :)
Pour le moment Mercurial est le (D)VCS que j'ai trouvé le plus agréable à utiliser et je suis content qu'il apparaisse dans cette 0.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 (Jabber id, page perso, ) le 25/11/2008 à 09:06. (lien). Évalué à 3.Peux-tu m'éclairer un peu et m'expliquer rapidement ce que sont les outils pull/clone de bitbucket ? Histoire que je garde ces idées au coin du crâne pour les prochains développements.
Merci !-
[^]Re: Très bon ça, le support Mercurial :)
Posté par Temsa (Jabber id, page perso, ) le 25/11/2008 à 18:33. (lien). Évalué à 2.Jette un oeil sur http://www.bitbucket.org/temsa/archetype-prototype-16/overvi(...) par exemple.
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 (Jabber id, page perso, ) le 27/11/2008 à 11:49. (lien). Évalué à 2.Merci, je viens de regarder. La chose qui me retient un peu est l'impression de devoir tout faire "dans" l'interface bitbucket. Comme je suis en train d'ajouter la revue de code post/pre commit, je pense intégrer cette idée via cette fonctionnalité.
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
Je suis intéressé par ce type de produit (c'est à dire interface web pour bug tracking, wiki et gestion du subversion/cvs/mercurial/etc...). Je connais Trac mais je le trouve un peu limité (mono-projet). InDefero a l'air d'être un bon produit, mais y'en a t'ils d'autres (je n'ai pas trouvé grand chose...) ?
"Nobody expects the spanish inquisition"
-
[^]Re: Retours sur ce type d'application
Posté par CrEv (page perso, ) le 25/11/2008 à 09:35. (lien). Évalué à 5.Après avoir utilisé quelques fois trac, je suis passé à redmine ( http://www.redmine.org )
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 ?
Question au leader du projet
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 (Jabber id, page perso, ) le 25/11/2008 à 10:37. (lien). Évalué à 10.Bonjour Bozo,
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 () le 25/11/2008 à 10:58. (lien). Évalué à 3.Je te remercie pour cette réponse claire et argumentée
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 (Jabber id, page perso, ) le 25/11/2008 à 11:14. (lien). Évalué à 2.En effet, le problème des sous-tâches existe, une solution est de simplement discuter sur un ticket et le renommer au fur et à mesure, comme ici :
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 () le 25/11/2008 à 11:00. (lien). Évalué à 4.Je me permets aussi de rajouter le lien vers le framework dont tu parles
car il n'est pas référencé dans la news
http://www.pluf.org/-
[^]Re: Django ?
Posté par Cørtø () le 25/11/2008 à 13:44. (lien). Évalué à 2.Concernant ce framework, il serait interessant, Loïc, que tu (quelqu'un de ton équipe de dev) ailles renseigner la page Wikipédia correspondante.
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...--
Corto-
[^]Re: Django ?
Posté par Loïc d'Anterroches (Jabber id, page perso, ) le 25/11/2008 à 14:30. (lien). Évalué à 4.Merci Cørtø, je viens de faire l'ajout, je n'y avais pas pensé du tout.
-
[^]Re: Django ?
Posté par Bozo le Clown () le 25/11/2008 à 14:45. (lien). Évalué à 5.Y'en a une tripotée dis donc !
Et quand tu dois en choisir un, tu fais pluf pluf ?
Oui .... euh d'accord, c'est par là => [ ]-
[^]Re: Django ?
Posté par Cørtø () le 25/11/2008 à 15:03. (lien). Évalué à 1.C'est un peu hors sujet par rapport au topic, mais je cherche actuellement un framework php.
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--
Corto-
[^]Re: Django ?
Posté par Loïc d'Anterroches (Jabber id, page perso, ) le 25/11/2008 à 19:35. (lien). Évalué à 3.C'est difficile d'avoir un retour d'expérience, pour la simple et bonne raison que cela prend du temps d'apprendre les détails d'un framework pour pouvoir ensuite bien l'utiliser, puis passer au suivant et comparer.
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
-
-
-
-
-
Cette page a été générée par Templeet en 0.118s (dont 0.033 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.