Ludo a écrit 144 commentaires

Ce n'est pas ce qui se passe déjà pour la création de sites Web ;-) ?

C'était en parti dû à Rails.

Avec le dernier Redmine, ils utilisent Rails 2.3, ça consomme moins de ressources.

Je ne connais pas e-venement, uniquement CiviEvent, qui est un module CiviCRM, qu'on peut intégrer dans Drupal: http://civicrm.org/civievent

Quelqu'un ici présent aurait-il une expérience sur les deux outils, pour les positionner l'un par rapport à l'autre ?

Vous avez tous les deux raison ;-)

Passenger est recommandé, mais Passenger dans Gentoo a eu pas mal de problèmes (je n'en connais pas la raison), j'ai dû garder une certaine version de Passenger dans la Gentoo pour que cela fonctionne correctement.

Gitosis fonctionne très bien, l'utilisation de clés SSH me semble justement une bonne idée, notamment pour les déploiements.

Il faut 30 secondes pour générer une clé SSH (ssh-heygen), et c'est fait une fois pour toute.

Donc le côté pas simple, j'ai du mal à voir.

Bien que l'implémentation LLVM soit "jeune", ils ont déjà des performances proches. J'imagine donc qu'ils ont encore de la "marge" sur ce qu'ils peuvent faire, même si je n'ai aucune preuve pour l'étayer.

Merci pour les infos, c'est justement la performance du code généré qui me semble plus importante que la vitesse de compilation (on utilise plus souvent un programme qu'on le compile ;-) )

C'est néanmoins bien parti pour qu'ils "explosent" les performances de GCC.

Je ne connais pas ce hoster, mais ça me semble plus secure et flexible d'utiliser des clés SSH plutôt que filtrer par IP.

Tu ne peux pas leur proposer cette alternative ?

Ma tendre moitié a les mêmes besoins que la tienne, elle a un laptop sous Linux qu'elle gère quasi toute seule depuis 5 ans.

Pourquoi ne pas la convertir à Linux directement, si elle est prête à changer ?

>> c'est pas les produits Wiki libres qui manquent
> C'est sur, mais sont-ils au niveau ?
> Il faut noter aussi que les softs d'Atlassian ont l'avantage de pouvoir discuter entre eux et peuvent tous s'interfacer

Pour avoir migrer de JIRA+Confluence vers Redmine, l'utilisation et l'intégration est de meilleure qualité.
Certes, Confluence a quelques fonctionnalités en plus par rapport au wiki de Redmine, mais au moins c'est un outil simple à utiliser au quotidien est en plus c'est sous licence GPL.

http://fr.wikipedia.org/wiki/Network_address_translation

ce n'est pas plus compliqué à installer qu'une application PHP, à partir du moment que tu utilises une bonne distribution.

Pour moi, le gain de productivité de Redmine compense largement les "efforts" pour l'installer.

Et avec la virtualisation, tu peux mettre ça dans une VM si vraiment tu veux séparer les différents types de technologie.

Au boulot nous utilisons aussi Git.

Nous l'avons couplé à Redmine qui fonctionne aussi avec PostgreSQL: http://www.redmine.org/

Je ne connais pas du tout CodingTeam, donc je ne sais pas les différences entre les deux logiciels.

Tout ce que je peux dire, c'est que ça fait 2 ans qu'on utilise Redmine, on en est très satisfait par rapport aux tests qu'on avait fait à l'époque:
(du pire au mieux) Basecamp, JIRA, dotProject et Trac avec plugins.

Au niveau de la virtualisation, c'est justement un des projets qui a le plus de nouveautés justement: http://www.linux-kvm.com/

Par contre, c'est vrai que le projet est encore jeune, mais pour l'instant, ça fonctionne bien.

J'étais un peu faché contre Kubuntu, mais depuis la dernière version, KDE fonctionne bien.

Vu que tu aimes bien tester des logiciels et que ton outil de travail collaboratif ressemble d'un point de vue fonctionnel à un outil que j'utilise au quotidien, je ne sais pas si tu connais Redmine: http://www.redmine.org/
Il est codé en Ruby on Rails et possède pas mal de plugins intéressants.

Bravo en tout cas pour toutes tes contributions.

+1

A noter que portage, l'outil utilisé chez Gentoo pour gérer les logiciels, est codé en python à ma connaissance.

En effet, le "workflow" de base dans redmine n'en a que le nom.
Par contre, via l'écriture d'un plugin, tu as moyen de faire des choses intéressantes grâce à Ruby.
Ca prend plus de temps que dans JIRA, par contre au final je trouves que tu as une meilleure flexibilité.

Pour les roadmap, je ne connais pas bien celui de JIRA.
Mon principal reproche dans Redmine est le manque d'une case à cocher pour signaler la fin d'une version.
De plus, le calcul de la barre de progression n'est pas top, toutes les issues ont le même poids pour faire avancer la barre.

Par contre, dans le plugin budget, tu as une barre de progression qui tient compte des estimated time afin de connaître la "grosseur" de la tâche, ça permet d'avoir une meilleure idée de l'état d'avancement du projet.

Surtout que beaucoup moins de paquets ont des mise à jour de sécurité, chez Debian c'est tous les paquets, alors que chez Ubuntu, universe & cie n'a pas de support de sécurité.
A moins que ça ait changé depuis le temps ?

Pour avoir aussi participer à ce genre de sélections, et avoir vu l'utilisation au quotidien sur 2 projets pilotes, un avec Redmine, l'autre avec JIRA, il n'y a pas vraiment photo, à tel point que l'équipe qui utilisait JIRA a réclamé de migrer en cours de projet vers Redmine pour gagner en efficacité.

Après, il y a aussi un aspect temporel, Redmine est plus jeune que JIRA, donc il est bien possible qu'à l'époque où cette décision a été prise Redmine n'existait pas ou manquait de fonctionnalités.

Gniii ?

Si j'ai déjà du mal à comprendre qu'ils aient choisi cette usine à gaz peu ergonomique, où tu dois faire 36 clicks pour faire une action (j'exagère à peine), que tu dises que JIRA est un bon bug tracker tout en connaissant Redmine, là je suis vraiment perplexe ?

Aurais-tu des exemples concrets de fonctionnalités dans JIRA qui seraient manquantes ? As-tu déjà regardé les plugins de Redmine qui permettent de bien couvrir les besoins: http://www.redmine.org/wiki/redmine/Plugin_List

Je confirme, le multi-écran, j'en fais tous les jours avec KDE, je change souvent d'écran, ça marche très bien, les plasmoids sont à la bonne place à chaque fois.

Par contre, l'outil de conf du multi-écran KDE est bof, je préfère utiliser arandr pour l'instant.

arandr est un très bon outil pour configurer ce genre de choses.
Il génère même un script shell pour éviter de passer par le GUI la fois suivante.

Cela n'empêche pas néanmoins de devoir définir correctement ton VIRTUAL.

En ce qui concerne la gestion des fenêtres, barre de tâches et cie, tout fonctionne correctement avec KDE 4.2

Quand ton formulaire est en page d'accueil, par exemple un formulaire de login, ça coûte du CPU/RAM/BP en plus d'être en SSL par rapport à la version non sécurisée, or tout le monde qui vient sur ton site ne va pas se logguer.

C'est la même raison qui fait que certains services comme Gmail n'utilisent SSL que pour le login. (Oui, je sais, on peut être en SSL tout le temps avec Gmail, mais par défaut, c'est juste le login).

Dans le cas présent, vu qu'il faut cliquer pour arriver à ce formulaire, oui, ils auraient pu le mettre aussi en SSL.

L'important, c'est que le form pointe vers une adresse en https, le formulaire lui-même n'a pas besoin d'être sécurisé, seulement l'envoi des données.

Sur quoi pointe ce formulaire ?