Comme plus de 1250 personnes, vous pouvez avoir votre forge hébergée pour vous ou l'installer sur votre serveur (même un tout petit VPS ou une offre mutualisée un peu robuste). Pour chaque projet de votre forge vous pouvez proposer une zone de téléchargements, un suivi des bugs, une documentation wiki, un parcours de l'arborescence de votre dépôt ainsi que la revue de code. Chaque partie peut être plus ou moins ouverte, vous pouvez aussi bien gérer un projet avec le code source en accès libre que garder le source accessible juste aux développeurs.
Les fonctionnalités de base sont :
- interface web vers vos dépôts Subversion, Mercurial ou Git (chaque projet choisit son SCM) avec contrôle des droits d'accès directement dans l'interface ;
- wiki pour la documentation avec possibilité de synchroniser une page avec le contenu du dépôt ;
- tickets pour le suivi des bugs ;
- revue de code ;
- zone de téléchargement pour mettre à disposition des fichiers.
InDefero est aussi pour moi une expérience de développement d'un logiciel sous licence GPL auto financé. Aujourd'hui, vous pouvez utiliser InDefero en l'installant sur votre serveur ou, au choix, en profitant de l'offre hébergée. Contrairement à toutes les autres « offres » d'hébergement, avec InDefero, vous avez accès au dump SQL de toutes vos données et vous pouvez facilement migrer en dehors de l'offre car le dump est compatible avec la version GPL. Aujourd'hui, plus de 1250 forges sont actives sur la version hébergée.
Est-ce que l'offre hébergée pourra effectivement financer le développement d'InDefero ? Je ne sais pas, mais dans tous les cas, elle a le mérite d'améliorer énormément la qualité du logiciel, en effet, tous les bugs sur la plate-forme sont facilement reproductibles et donc faciles à corriger. Pour le moment, 50% des coûts de l'infrastructure sont supportés par les utilisateurs, ce qui n'est pas si mal.
Venez essayer InDefero et dîtes nous ce que vous en pensez !
Aller plus loin
- InDefero (239 clics)
- Offre d'hébergement (23 clics)
- Captures d'écrans (86 clics)
- Téléchargement (25 clics)
- Pluf Framework (11 clics)
# C'est compliqué a installer!
Posté par Brioche4012 (site web personnel) . Évalué à 3.
Mon hébergeur ne me permet pas d'exécuter de scripts shell et rour cela fait beaucoup de manipulations pour avoir quelque chose de simple, alors j'ai laissé tomber.
Un installeur simple et digne de ce nom serait sans doute grandement apprécié!
[^] # Re: C'est compliqué a installer!
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 3.
En fait, la direction future (déjà prise par Archlinux) est de proposer des paquets directement pour chaque distribution.
[^] # Re: C'est compliqué a installer!
Posté par Victor . Évalué à 1.
Personnellement, je n'ai pas réussi à l'installer au boulot où je n'ai qu'un accès ftp à mon répertoire web (je comptais l'utiliser sans dépo pour le moment) !
Si en plus SQLite était complètement supporté, ce serait le must :)
En tout cas ça fait plusieurs mois que je bave dessus pour l'utiliser au boulot, ça a l'air d'être super.
[^] # Re: C'est compliqué a installer!
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 1.
Pour SQLite le problème vient des mises à jour de la base. SQLite n'a qu'un nombre limité de commandes "ALTER TABLE ...".
Merci pour votre patience...
# InDefero 0.8.7 ?
Posté par pampryl . Évalué à 4.
J'aurais aussi apprécié une petite liste des changements qu'apporte cette nouvelle mouture.
En tout cas, c'est une forge que j''utilise et recommande. L'utilisation est très agréable (quoi qu'un peu lente) et l'ergonomie me va très bien. Le seul point noir était au moment où je l'ai installé, la documentation. Mais ce point semble s'améliorer.
Merci aux développeurs pour le travail accompli.
[^] # Re: InDefero 0.8.7 ?
Posté par CrEv (site web personnel) . Évalué à 2.
juste pour avoir des précisions, quel lien alors avec tiré de la news
Sinon, comme le commentaire précédent, une installation simplifiée serait réellement appréciable, même si ça ne m'empêchera pas de le retester bientôt (j'utilise redmine pour le moment, mais InDefero me semble assez agréable à utiliser et faisant suffisament de choses pour moi)
Reste à voir (j'ai pas encore cherché, donc patapai) comment fonctionnent les workflow de gestion de bug (important pour moi)
[^] # Re: InDefero 0.8.7 ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Dans le même style, il existe Retrospectiva [http://retrospectiva.org/], qui, bien que pas très connu, mérite d'être essayé.
[^] # Re: InDefero 0.8.7 ?
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 2.
Sinon, pour la lenteur, on est tous (sur le channel IRC) un peu étonné et je me demande si tu pouvais nous donner un peu plus de détails sur ton installation et le SCM utilisé ? InDefero est optimisé (et Pluf aussi) en continu à coup de Kcachegrind donc, bon, cela nous parait bizarre.
Si tu as une instance memcached, mettre cela dans la config pour l'utiliser pour la mise en cache des infos pourrait aider :
$cfg['cache_engine'] = 'Pluf_Cache_Memcached';
$cfg['cache_timeout'] = 300;
$cfg['cache_memcached_keyprefix'] = 'domaine.indefero';
$cfg['cache_memcached_compress'] = 0;
Par défaut cela utilise une cache disque qui n'est pas la plus performante.
[^] # Re: InDefero 0.8.7 ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Par exemple, est-ce que InDefero utilise des javascripts qui pourraient ralentir le chargement de la page ? Un bon point de départ pour ce genre d'optimisations est les règles d'Yslow [http://developer.yahoo.com/yslow/help/#guidelines].
[^] # Re: InDefero 0.8.7 ?
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 4.
On travaille vraiment beaucoup sur l'optimisation de la bestiole, avec 1200 forges hébergées et la très grosse forge d'Intuxication[1] on n'y échappe pas. Le passage de la forge de Céondo[2] sur une tranche Gandi 256Mo fait partie de ce travail de toujours pousser le logiciel à ses limites.
Pour moi, un problème de performance est un bug critique, donc je suis là pour travailler dessus.
[1]: http://www.intuxication.org
[2]: http://projects.ceondo.com
[^] # Re: InDefero 0.8.7 ?
Posté par pampryl . Évalué à 2.
Je n'ai pas beaucoup de temps dans l'immédiat pour fournir plus d'infos, mais j'ai remarqué que l'exploration de repository SVN est un peu lente à mon goût.
Il faut aussi que j'avoue être resté à la 0.8.2... c'est peut être amélioré depuis (il faudrait que je prenne le temps d'upgrader mais ma tentative pour passer à 0.8.4 il y a quelques mois m'avait un peu fait peur...)
Voila quelques détails supplémentaires :
- machine assez puissante et très peu chargée
- SVN partout
- Je n'utilise pas memcached (c'est peut être préconisé?)
- apache2
- moins de 10 projets
Je vais me donner le temps dans la semaine de (tenter de) migrer en 0.8.7 pour voir si je ressens toujours le problème.
[^] # Re: InDefero 0.8.7 ?
Posté par pampryl . Évalué à 2.
Résultat similaire. Je tenterais memcached demain je pense pour voir si ça résoud ce problème.
[^] # Re: InDefero 0.8.7 ?
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 3.
# Support de Mylyn
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 2.
En effet, beaucoup de personnes aujourd'hui se tournent vers Trac grâce à (ou à cause de) Mylyn. Les autres forges/bugtrackers actuellement supportés par Mylyn sont JIRA (proprio) et bugzilla. Le support d'Infero par Mylyn serait un vrai plus.
Pour information (et de manière très schématique), Mylyn est un plugin pour Eclipse très apprécié des développeurs qui fait office de gestionnaire de tâches/client pour des systèmes comme bugzilla/Trac/JIRA.
http://www.eclipse.org/mylyn/
http://fr.wikipedia.org/wiki/Mylyn
[^] # Re: Support de Mylyn
Posté par nomorepost . Évalué à 3.
Le support au travers du "generic web repository" s'etend à d'autres bugtrackers libres, par exemple Redmine:
http://www.redmine.org/wiki/1/HowTo_Mylyn
[^] # Re: Support de Mylyn
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 3.
[1]: http://shoss.de/blog/2009/indefero-mylyn-connector/
# Contexte d'utilisation
Posté par Mathias Bavay (site web personnel) . Évalué à 1.
Cela tombe bien, je suis à la recherche d'une forge avec hébergement... Je travaille dans un labo qui entre autre développe des modèles numérique (sur le domaine de la neige et les avalanches). Nous utilisons pour l'instant notre propre serveur SVN, qui est sur notre réseau local, derrière un pare feux. Comme je cherche à ouvrir le développement le plus possible, il nous faudrait un serveur SVN externe, ainsi que des outils de gestion de projet. Cela signifie les pré requis suivants:
*il faut pouvoir héberger aussi bien des projets GPL que des projets proprio (je voudrais bien que tous soit GPL, mais nous avons des bouts de codes dans certains projets qui ont été financés avec certaines restrictions)
*il faut un SVN (accessible aussi via un client SVN standard), un wiki pour la doc et communiquer avec les utilisateurs (ie: annoncer de nouvelles versions, etc) et un bug tracker
*si la partie web peut ne pas avoir une fiabilité excellente, le dépôt SVN doit être très disponible (nous travaillons quasiment tous les jours dessus, il ne faut donc pas qu'un jour sur deux le dépôt ne soit pas accessible)
*il faut des backups sérieux (car il s'agit de notre base de code, ce sur quoi nous travaillons, ce pour quoi nous recevons des financements, etc)
*évidement, il faut que nous ayons la possibilité a tout moment de récupérer notre base SVN (cela ne veux pas dire que nous allons partir à peine arrivés, mais comme il s'agit du code sur lequel nous investissons beaucoup, il faut que l'on garde toujours la possibilité de migrer vers autre chose, que l'on garde la possibilité de reprendre en main notre projet)
Est ce que InDefero peut satisfaire à cela? (ie: est ce que InDefero est prêt pour ce genre d'utilisation?)
Mathias
[^] # Re: Contexte d'utilisation
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 2.
pour ce que je lis de la description des besoins, Indefero répond totalement à ce genre de besoins. L'intérêt de l'offre, contrairement à la majorité de ce qui se fait, est qu'il est possible de récupérer l'intégralité des données (dump PostgreSQL pour le moment mais bientôt dump JSON avec les outils pour faire l'import dans PostgreSQL, SQLite ou MySQL) ainsi que le dump subversion (svnadmin dump) quotidien.
Le backup est fait dans un autre centre de données (Gandi) que le principal (OVH) avec warm standby de la base de données (merci PostgreSQL) et bientôt backup temps réel des données des dépôts[1].
Une fois le backup temps réel des données des dépôts effectué, cela permettra de passer instantanément d'un centre à l'autre en cas de pépin avec le minimum de perte de données et d'interruption de service. La sécurité/disponibilité des données est un point crucial de l'offre (en fait c'est le point majeur).
Les modèles numériques pour les avalanches, c'est sympa ça, à Davos ils ont un bon centre de recherche dans le domaine, mais je ne sais pas s'ils font de la modélisation.
loïc
[1]: http://www.ceondo.com/ecte/2009/10/new-backup-strategy-indef(...)
[^] # Re: Contexte d'utilisation
Posté par Mathias Bavay (site web personnel) . Évalué à 1.
Les modèles numériques pour les avalanches, c'est sympa ça, à Davos ils ont un bon centre de recherche dans le domaine, mais je ne sais pas s'ils font de la modélisation.
Bah si, la preuve, j'y travaille et je m'occupe des codes de manteau neigeux, codes que je voudrais mettre dans un hébergement externe (et par étape passer en GPL).
Mathias
[^] # Re: Contexte d'utilisation
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 1.
[^] # Re: Contexte d'utilisation
Posté par Antoine . Évalué à 3.
Dans ce cas, utilise un DVCS comme Mercurial, n'importe quel clone du dépôt est aussi un réplicat intégral du dépôt.
Gros avantage des DVCS par rapport à SVN : la simplicité d'administration.
il faut des backups sérieux
Pareil, avec un DVCS, n'importe quel clone est un backup.
# Maintenant que la grosse vague est passée
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 3.
loïc
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.