Bruno Michel a écrit 3286 commentaires

Tu n'aurais pas juste envie de troller sur Mozilla sans chercher à comprendre leurs motivations ?

Les utilisateurs de la beta de Firefox-4.0 peuvent remonter des informations quand le navigateur a crashé. L'analyse de ces informations a permis à Mozilla de se rendre que de nombreux crashs venaient de l'accélération matérielle avec les drivers ATI, Nouveau, etc. Le seul driver qui semblerait ne pas poser de problème est (malheureusement) un driver proprio, celui de Nvidia.

Mozilla a donc provisoirement désactivé l'accélération matérielle sous GNU/Linux avec les drivers libres. Ce n'est qu'une mesure provisoire en attendant de pouvoir corriger ces problèmes. L'accélération matérielle sera réactivée pour tous les drivers qui passent les tests de https://cvs.khronos.org/svn/repos/registry/trunk/public/webg(...)

> sinon, devoir installer Python pour compiler un pauvre programme C ... euh ... Jen e sais pas pourquoi mais ça me gène.

La version actuelle de redo est en python, mais son auteur indique qu'à terme, il compte bien le réécrire en C.

> Je pense pas que make soit un pb, il fait ce pourquoi il a été conçu : gestion de dépendance.

Bah, même pour la gestion des dépendances, make n'est pas si bien que ça. Ce n'est pas facile d'avoir un Makefile générique qui sache recompiler juste les fichiers nécessaires quand un .h a été modifié. Ou qui ne refasse que la phase d'édition de liens quand on change LDFLAGS.

Il y avait aussi plein de remplaçants de CVS avant l'arrivée de Git (et mercurial). Ça ne l'a pas empêché de marquer une nette avancée.

Ça ne veut pas forcément dire que redo va devenir l'équivalent de git, mais l'argument qu'il y a déjà plein d'outils pour faire ça n'est pas suffisant pour le rejeter.

Ça ne me paraît pas idéal comme Makefile : si tu modifies un .h et que tu relances make, il ne se passera rien.

La syntaxe des Makefile simple ? Déjà, il ne faut pas confondre les espaces et les tabulations. Puis, il vaut mieux ne pas avoir de fichiers dont le nom contienne une espace. Et plus généralement, la syntaxe est simple sur les cas de bases mais peut vite devenir horrible sur des cas particuliers.

Effectivement, je corrige ça.

Là, je suis encore plus perplexe. Je traduis le site officiel de Ruby (ruby-lang.org) et je ne vois pas d'attaques qui puissent concerner Redmine.

> Pour moi le plus gros inconvenient c'est que c'est RoR/Ruby. Je n'aime pas parce que c'est lente, bourre de trous de securite [...]

Gni, quels trous de sécurité ??

On vient de me parler d'un autre concurrent pour Redmine : Vermis (en PHP). À première vue, rien de bien excitant, mais je bloque sur un détail : les tickets sont appelés "Problèmes" dans la version française. Je ne me vois pas cliquer sur "Ajouter un problème" pour proposer une amélioration.

Vermis : http://vermis.diabloware.com/

Bon, après mise à jour de markitup.css, le cadre ne s'affiche plus à voté ... mais bien plus bas (apparemment, il attend que la colonne de gauche soit finie).

C'est possible que ce soit un bug dans la feuille de style markitup importée. Je viens de me rendre compte que je ne l'ai pas mise à jour quand je suis passé à une version plus récente de markitup.

C'est sur github : https://github.com/nono/linuxfr.org/issues#issue/103

Il n'y a eu aucune participation pour la killer feature HTML5. Il semblerait que les gens qui ont essayé n'ont pas trouvé d'idées pertinentes pour ça.

> Je me sens un peu lésé. J'ai passé du temps. J'ai fait des patchs presque tous sans régression.

Sans régression sur la feuille de style originale, mais ils ont des effets sur les autres CSS du concours. Je ne m'attendais pas à recevoir des patchs sur le HTML le dernier jour du concours et du coup, je ne sais pas trop quoi en faire pour le moment.

> J'ai écrit une documentation et des commentaires.

À ce sujet, est-ce que ce serait possible d'ouvrir ta forge sur Indefero ?

> La moindre des choses aurait été de nous prévenir avant de publier la nouvelle et le sondage non ?

Il me semblait évident que les CSS allaient être publiées peu après la fin du concours mais ce qui est évident pour moi ne l'est pas forcément pour les autres, et j'aurais sûrement dû communiquer dessus.

Il corrige la feuille de style de base mais pas toutes les autres feuilles de style. Le patch serait arrivé plus tôt, j'aurais pu l'appliquer sur alpha pour que les autres auteurs de CSS puissent en tenir compte mais il est arrivé hier.

2PetitsVerres a aussi un patch non appliqué pour ajouter la date sur le coté des dépêches. Et comme pour lui, je peux juste m'engager sur le fait que si ta CSS devient la nouvelle CSS par défaut du site, tes patchs seront appliqués (et les autres CSS alternatives devront s'adapter).

Ouais, enfin tu sais ce que l'on dit : « Quelle est la différence entre la théorie et la pratique ? En théorie, aucune, mais en pratique... »

En l'occurrence, il peut y avoir pas mal de petits points qui changent :
- le bug qui fait qu'il manque une classe CSS (oops, ma faute)
- peu de contenus sur la machine virtuelle, et on peut avoir des surprises sur la quantité de contenus
- j'ai modifié les CSS pour n'utiliser que des ressources locales (les URL des images et polices) et ça m'arrive de faire de faire des erreurs
- le code et la structure HTML ont évolué durant le concours, une CSS bien propre il y a 1 mois pourrait avoir des bugs maintenant.

Ceci étant dit, le jury du concours se compose de l'équipe des AMR et nous n'avons pas encore commencé à voter.

Ca y est, je crois que j'ai trouvé : cette partie est mise en cache et le cache datait d'avant la modification. Pffiou, ce fût dur.

> NoNo, ma feuille de style (colors) ne s'affiche pas correctement sur le site car la class ".active" n'est pas présente sur le lien de menu.

Oui, en local, ça marche bien, mais je n'arrive pas à trouver pourquoi cette classe est absente sur alpha :/

> Le logo de connexion sécurisé n'est pas non affiché correctement. Mon affichage utilise un lien et du CSS, voir le patch j'ai envoyé. Du coup lorsque l'utilisateur est connecté le logo n'est pas au bon endroit.

Je n'ai pas appliqué pour ne pas casser les autres CSS.

> Un autre bug est celui de la page d'erreur 404 qui inclut toujours le CSS par défaut.

Il est toujours là : https://github.com/nono/linuxfr.org/issues#issue/10

> Si la bannière est toujours relevante est-ce possible de glisser une aside.banner {display: none;} dans ma CSS ?

La bannière est toujours d'actualité, j'ajoute la ligne en question.

> Color est très original mais le bandeau du haut qui prend 1/3 de la hauteur de mon écran avec des couleurs flashy je trouve ça ignoble. Donc j'ai réduit la hauteur avec firebug et ça va déjà beaucoup mieux. Je ne sais pas si c'est un bug ou quoi parce que sur le screenshot, ce n'est pas du tout comme ça !

Oui, c'est un bug. Il manque une classe CSS et je n'arrive pas à voir pourquoi :-/

Voilà, le sondage est là : http://alpha.linuxfr.org/sondages/parmi-les-css-propos%C3%A9(...)

Je l'ai mis sur alpha pour avoir assez de possibilités pour lister toutes les CSS.

Effectivement, on aimerait bien un coup de main sur ça : cf http://linuxfr.org/comments/1180303.html#1180303

:)

Bien essayé mais le serveur actuel de LinuxFr.org s'appelle zobe.linuxfr.org ;-)

Yep, il y avait une petite coquille dans le HTML (2 fois <a) sur ce lien. C'est corrigé.

Et merci pour le journal :-)

> Pourquoi vouloir changer ?

Le web s'améliore progressivement et les gens deviennent en conséquence de plus en plus exigeants. Si LinuxFr.org ne change pas, il va progressivement devenir de moins en moins attirant et décliner petit à petit jusqu'à disparaître. Je ne connais aucun site qui existe depuis longtemps, qui n'a pas changé et qui soit encore actif.

Un exemple de changement : pour le moment, les dépêches proposées doivent être écrites en HTML et cela va être remplacée par du markdown (une syntaxe wiki). Il y a 10 ans, il était normal d'écrire tout contenu destiné à être publié sur le web en HTML. Mais depuis les wiki sont passés par là (et notamment wikipedia), et les lecteurs s'attendent plus à une syntaxe wiki (ou un éditeur WYSIWYG).