- la balise h qui permettait de ne pas spécifier de nombre après et qui, en combinaison avec la balise section donnait des trucs vraiment bien structuré [1]
- la balise l qui permettait de spécifier une ligne sémantique [2]
Ouai, mais seulement ce genre de truc est un cauchemar à styler. Comment styler les titres de deuxième niveau par exemple, et uniquement de deuxième niveau ?
Et ce n'est pas un cauchemar seulement pour les développeurs web, mais aussi pour les implémenteurs des moteurs de rendu, d'après ce que j'avais lu. Cela apporte des problèmes mais je ne me rappel plus quoi.
- le détournement du sens de dt et dl où le d pourra signifier definition (comme en (X)HTML) mais aussi maintenant dialog, des éléments schizophrène donc. Ça va être simple d'apprendre le HTML5 : ça veut dire quoi dt ? ben le d veut dire : ça Dépend...
Le d veut dire description. Pour les dialogs, tu as maintenant une balise dialog. Pour les définitions, une balise dfn. Bref, je vois pas ce qu'il y a de schizophrène là dedans. C'est dans HTML4 que dl était schizo.
la floppée de nouvelles balises inutile dans 99% des cas progress, meter, etc..
Je ne te comprend pas. Tu te plains que soit-disant on perd les avançées sémantiques de XHTML2, alors que ces balises justement, avec dialog et dfn par exemple que j'évoquais juste au dessus, apporte de la sémantique.
Bon sinon pour ton information, progress et meter peuvent être utilisé dans une interface d'application web. Et ça pourra être utile pour les applis qui prennent en charge le mode offline. Genre le mode online est de nouveau actif, l'appli va alors sauvegarder les infos modifiées pendant le offline, et donc pourra afficher simplement un progress pour indiquer à l'utilisateur qu'il est en cours de sauvegarde... (par exemple)
la disparition de l'attribut align dans la balise table : faudra m'expliquer comment, en CSS, je centre un tableau sans mettre de balise div autour
bah margin:auto sur la table...
Enfin bref. Il ne faut pas oublier que ce n'est qu'un brouillon. Des choses vont certainement disparaitre, ou réapparaitre, ou être modifié.
Et dans Firefox 3, d'après ce que je vois dans les logs de commits, ils sont en train de corriger des bugs dans le support de MATHML. (bon maintenant n'ayant pas fait de Mathml, je peux pas te dire si ce sont des corrections de bugs importants ou non).
Tu ne confonds pas XHTML 2 et XForms ?? Je ne vois pas le rapport entre les deux... C'est pas parce que XHTML 2 est abandonné que Xforms va l'être. Ou alors y a des raisons que je ne connais pas ?
C'est pas demain la veille que TOUTE la specification soit implémenté, mais les éditeurs de navigateurs l'implémente au fur et à mesure :
- mécanisme offline et stockage locale est operationnel depuis FF2
- canvas dans FF2 et Safari
- video en cours de dev dans FF et Opera (j'ai testé dans un FF experimental, ça marche pas trop mal ;-) )
- dans HTML5, y a pas mal de truc similaire à XUL, donc l'implémentation dans Firefox de certaines choses ne devront pas prendre trop de temps ;-)
Enfin bref, ça avance, ça avance, faut arrêter d'être pessimiste :-p Surtout quand on sait que c'est le WHATWG donc Mozilla-Opera-Apple qui pousse le HTML5. Si ils sont derrière, c'est qu'ils sont d'accord pour implémenter rapidement non ?
Conçernant IE, vu encore leur dernière connerie en date d'activer le mode standard dans IE8 avec une balise meta (ouai chouette, trois mode de rendu à prendre en compte !), je crois que les developpeurs web vont en avoir ras le bol et pousser encore plus à l'adoption d'autres navigateurs.
Bien que les formulaires dans HTML5 soient grandement amélioré (voir une présentation ici http://ljouanneau.com/blog/2006/08/30/587-web-forms-2 ), XForms reste, et de loin, bien plus riche (et plus complexe aussi, mais bon..), offrant plus de possibilité.
XForms est beaucoup utilisé en dehors du web, ou coté serveur.
Dans FF3, il y a un garbage collector. Parce que le comptage de référence, c'est bien mais pas suffisement. Genre un objet A detient un objet B, et B detient A. Si il n'y a pas de garbage collector, jamais A et B ne seront détruits.
personnellement, j'ai installé la dernière kubuntu sur trois machines totalement différentes, et je n'ai eu à faire aucun bidouillage.
Quant au choix de krita, je ne vois pas en quoi c'est un manque de discernement : je trouve normal d'avoir des logiciels kde/qt dans un environnement kde (meilleure intégration), et je trouve que krita a de moins en moins de choses à envier à gimp (surtout pour un usage "normal").
Bon et puis on peut pas dire que apt-get install ou l'utilisation de adept soit particulièrement compliqué pour installer tes logiciels préférés (non mais).
>N'y aurait-il pas moyen d'utiliser quelque chose du type des annotations qu'on retrouve sur JPA dans Java EE 5?
Je ne sais pas, je ne connais pas JPA :-)
Ceci dit, pour les fichiers XML, il y a des scripts en ligne de commande fourni pour les générer, et pour les DAO en particulier, à partir de la base. (Et ils ne sont pas généré à la volée car il n'est pas toujours possible de tout détecter au niveau du schema selon la base, selon la qualité du schema etc...)
Je suis sous KDE depuis des années, j'adore KDE, mais je préfère Firefox à Konqueror... Et j'aimerais bien aussi une meilleure intégration de FF dans Kde...
justement, si ils n'utilisent pas CVS ou peu, c'est peut être parce que CVS c'est franchement dépassé et franchement pénible à utiliser, non ? Et donc peut être que si vous migrez vers un outils plus moderne et plus simple d'utilisation...
il me semble qu'il y a eu des améliorations aussi de ce coté là, mais je te confirme rien, j'ai pas regardé cet aspect.
Pour ce qui est de Firefox/QT, ben... quand il y aura des volontaires ?
Pour des raisons historiques, Gecko utilise GTK. Il y a eu dans le trunk Mozilla la possibilité de remplacer GTK par QT (c'est à dire plus de trace de gtk), mais le problème est que ceux qui avaient fait cette partie de code ne l'ont jamais vraiment maintenu. Ça compilait même plus d'ailleurs à un moment. Ils ont donc fini par virer dans le trunk (et donc FF3) le support QT et les sources qui allaient avec.
Mais bon, si des volontaires veulent s'investir à nouveau sur QT inside FF, c'est toujours possible.
Bizarrement, y a toujours eu des volontaires pour aider au support de GTK dans FF, mais jamais vraiment pour QT...
>Si il faut des plombes pour que un patche soit « accepté » par le reste des devs, ça va pas marcher. Et ça peut arriver si on ne donne pas d'accès en écriture car les mainteneur peuvent être occupé et penser qu'un autre répondra.
Y a pas de raisons qu'un patch soit intégrés après des plombs. Par exemple dans Mozilla, quand tu proposes un patch, et que tu demandes une revue, elle se fait dans les quelques heures ou jours, mais pas des semaines. Et ceci parce qu'il y a des responsables, des reviewers pour telle ou telle partie de code, et que la revue de code fait partie de leurs tâches (le code de mozilla est tellement gros qu'il n'y a personne qui connait suffisement bien *tout* mozilla pour pouvoir faire les reviews de n'importe quel patch).
bref, ton "ça va pas marcher" n'est pas vrai. Ça fonctionne dans de nombreux projets.
>Ça marche avec Wikipedia, ça marche avec KDE
Ouai enfin, la qualité des articles dans wikipedia est très très inégale. Et ils ne sont pas systématiquement toujours relus. Mais à la limite, on s'en fiche un peu, un mauvais article ne met pas en péril le projet. On ne peut pas en dire autant dans un projet informatique comme KDE : du mauvais code peut ajouter des trous de sécurité, des problèmes de stabilité etc... Je trouve donc ça hasardeux de comparer Wikipedia avec un projet informatique.
Autant je suis d'accord avec toi que le point 1 et 3 peuvent rendre agréable le développement, autant je ne suis absolument pas d'accord avec toi sur le point 2.
Ce n'est pas parce qu'on ne donne pas les clés à tout le monde au dépôt de source que le projet est moins communautaire. Très franchement, je préfère qu'une certaine confiance s'instaure entre les dirigeants d'un projet, et un contributeur, avant de lui donner les clés. Pourquoi ?
- parce que même si on peut annuler des modifs, c'est franchement une perte de temps que de corriger les merdes de contributeurs peu scrupuleux, codant comme des porcs, ou tout simplement débutant. Et dieu sait si le temps nous est particulièrement précieux.
- J'ai pas envie, sur mes projets que les types commit n'importe quoi, des fonctionnalités dans tout les sens, des trucs qui font dévier le projet de ses objectifs, ou encore des trucs inutiles, au risque de mettre en péril le produit même : au niveau stabilité, utilisabilité etc.. (c'est du vecu)
- Si on s'aperçoit qu'un type auquel on vient de donner l'accés, fait du mauvais boulot, c'est encore une perte de temps pour le virer (lui expliquer, tout ça...), et ce n'est jamais agréable pour les deux parties. En tout cas, c'est un risque fort de tuer l'ambiance du projet si le gars en question n'est pas content et qu'il fait des histoires parce qu'on lui a couper son accès. Éviter ce genre de problème, c'est des soucis en moins. Bref, je préfère qu'il y ait une sélection à l'entrée, plutôt que de devoir virer les gens.
- Corollaire : Ne pas donner accès en écriture à tout le monde est un gage d'une certaine qualité, en tout cas d'une qualité du niveau de ce qu'attendent les responsables du projet.
- Je ne vois pas franchement à quoi ça sert de livrer l'accés en écriture si il y a un outils de suivi (bugzilla ou autre) et qu'il est utilisé efficacement : n'importe qui peut faire un checkout, faire sa modif en locale, et proposer un patch dans un ticket. Où est le problème ?
De plus, tu penses qu'un processus de review c'est long et contre-communautaire : moi je dis que l'absence de review est synonyme de code pourri (en tout cas, pourrissement à moyen et long terme, donc de plus en plus dur à maintenir). Les reviews permettent d'une part aux nouveaux venus d'apprendre par leurs erreurs, et d'autre part de faire en sorte que le code commité soit d'un niveau de qualité minimal. Par exemple, dans Mozilla, les patchs, de qui que ce soit (qu'il soit débutant sur le projet ou un vieux de la vieille), sont revues par au moins deux personnes. Et pour un projet d'une telle complexité, c'est pas du superflu.
D'ailleurs, la revue de code est un des fondements des méthodes "agiles" de développement, et garantissent, avec les tests unitaires, d'une qualité **constante**, et en tout cas plus uniforme sur l'ensemble du projet.
Bref, je préfère donner les clés à des contributeurs qui ont montré par leurs contributions passées, qu'ils sont sérieux, qu'ils codent pas trop mal et qu'ils sont actifs.
Il est possible que les devs de KDE donnent accès en écriture à tous, mais je serais vraiment étonné si ils ne mettent pas des droits restreints sur certains répertoires...
Pour conclure, non, restreindre l'accès en écriture au dépôt de source n'est pas une condition pour que le développement soit agréable. Ça n'empêche nullement de coder, de proposer des patchs. Ce qui fait qu'il est agréable de contribuer à un projet, c'est le contact que l'on a avec les devs, c'est le fait qu'il ne soit pas fait n'importe quoi sur le projet, et donc qu'il y ait des objectifs clairs et définis, qu'il y ait un minimum de serieux (sans tombé dans une atmosphère dictatoriale), que les reviewers soient "pédagogiques" genre pas dire, "ton patch il est nul", mais expliquer pourquoi ici ou là ça ne va pas, qu'est ce qu'il est préférable de faire etc. Bref, avoir l'impression qu'on apprend quelque chose, qu'on avance tous ensemble dans la même direction.
Ah oui au fait, en utilisant des dépôts décentralisés, ton point 2 n'a pas lieu d'être... les dépôts centralisés sont has been, surtout pour les gros projets... (même si j'aime bien et j'utilise subversion :-) )
Il y a plein d'autres choses qui ont changé dans FF, des choses qui se voient : nouvelle gestion des bookmarks/historique par ex, icones, theme, et plein de petites choses dans l'interface, dans les préférences, amélioration de l'intégration dans le desktop.
Et des choses qui ne se voient pas : le moteur de rendu a eu des parties refondues pour un meilleur support de CSS, performances accrues, améliorations de la gestion de la mémoire, améliorations dans le support SVG, amélioration de l'accessibilité (ceux qui utilisent des lecteurs d'écrans par ex vont apprécier).
Pour tes problèmes de lenteurs : tu as manifestement un problème sur ta machine avec ton système. Les builds de Firefox subissent de manière incessantes des tests de perfs dans tout les sens, sur tout les types de machines courantes (windows, mac, linux...). Si il y avait de tels problèmes sur ces système "normaux", ça serait corrigé aussitôt.
Oui, c'est le serveur. Dans le test, il y a un lien qui doit pointé sur une page 404, or sur le serveur, il y a maintenant une page à l'url indiqué, donc plus 404, donc test faux.
Ça n'est pas au même niveau. Il parle ici des allocations/désallocations bas niveau.. Le garbage collector est une couche au dessus. Et puis bon, les allocations/desallocations sur la stack ne concernent pas vraiment le garbage collector...
>après une longue attente et diverses RC, signe que les développeurs voulaient sortir un produit de qualité et non pas bâclé
Ouai enfin, je suis dubitatif. Parce que bon, quand je vois qu'ils ont sorti 8 RC avant la finale, je me dis qu'il y a un problème quelque part :
- soit ils ont sorti la RC1 trop tôt, c'est à dire non débuggée et alors ils auraient dû l'appeler beta (pour rappel : RC= release candidate, c'est à dire une version censée être stable, suffisament débuggée, prête donc à être utiliser en prod)
- soit leur code est toujours aussi pourri (il n'y avait qu'à voir le nombre de requête SQL inutiles executée à chaque page dans les versions précédentes)
Enfin bref, 8 RC, pour moi ça ne fait pas sérieux et n'est pas un gage de qualité, et ils ont certainement des progrès à faire au niveau de la prise en compte de la qualité dans leur processus de développement (par exemple, je n'ai pas vu de tests unitaires dans le dépôt CVS).
[^] # Re: Plus que sceptique
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 5.
Ouai, mais seulement ce genre de truc est un cauchemar à styler. Comment styler les titres de deuxième niveau par exemple, et uniquement de deuxième niveau ?
Et ce n'est pas un cauchemar seulement pour les développeurs web, mais aussi pour les implémenteurs des moteurs de rendu, d'après ce que j'avais lu. Cela apporte des problèmes mais je ne me rappel plus quoi.
http://www.w3.org/TR/2008/WD-html5-20080122/#dl
Le d veut dire description. Pour les dialogs, tu as maintenant une balise dialog. Pour les définitions, une balise dfn. Bref, je vois pas ce qu'il y a de schizophrène là dedans. C'est dans HTML4 que dl était schizo.
Je ne te comprend pas. Tu te plains que soit-disant on perd les avançées sémantiques de XHTML2, alors que ces balises justement, avec dialog et dfn par exemple que j'évoquais juste au dessus, apporte de la sémantique.
Bon sinon pour ton information, progress et meter peuvent être utilisé dans une interface d'application web. Et ça pourra être utile pour les applis qui prennent en charge le mode offline. Genre le mode online est de nouveau actif, l'appli va alors sauvegarder les infos modifiées pendant le offline, et donc pourra afficher simplement un progress pour indiquer à l'utilisateur qu'il est en cours de sauvegarde... (par exemple)
bah margin:auto sur la table...
Enfin bref. Il ne faut pas oublier que ce n'est qu'un brouillon. Des choses vont certainement disparaitre, ou réapparaitre, ou être modifié.
[^] # Re: Et donc on le fait comment son site web?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 2.
[^] # Re: Et la sémantique dans tout ça ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 4.
Ba c'est comme qu'est qu'un moteur de recherche peut faire du contenu d'une image ou d'une photo ?
Faut voir canvas comme étant un truc pour faire une image dynamique. C'est pas plus et pas moins accessible qu'une video par exemple.
Si tu veux une image "accessible", tu fais du SVG.
[^] # Re: XForms
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 2.
[^] # Re: Eternité ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 3.
- mécanisme offline et stockage locale est operationnel depuis FF2
- canvas dans FF2 et Safari
- video en cours de dev dans FF et Opera (j'ai testé dans un FF experimental, ça marche pas trop mal ;-) )
- dans HTML5, y a pas mal de truc similaire à XUL, donc l'implémentation dans Firefox de certaines choses ne devront pas prendre trop de temps ;-)
Enfin bref, ça avance, ça avance, faut arrêter d'être pessimiste :-p Surtout quand on sait que c'est le WHATWG donc Mozilla-Opera-Apple qui pousse le HTML5. Si ils sont derrière, c'est qu'ils sont d'accord pour implémenter rapidement non ?
Conçernant IE, vu encore leur dernière connerie en date d'activer le mode standard dans IE8 avec une balise meta (ouai chouette, trois mode de rendu à prendre en compte !), je crois que les developpeurs web vont en avoir ras le bol et pousser encore plus à l'adoption d'autres navigateurs.
[^] # Re: XForms
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 5.
XForms est beaucoup utilisé en dehors du web, ou coté serveur.
[^] # Re: Une syntaxe non xml
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 6.
HTML5 == XHTML5
http://www.w3.org/TR/2008/WD-html5-20080122/#html-vs
En gros, pour le HTML5, tu as le choix entre la syntaxe SGML (le HTML quoi), et la syntaxe XML (donc XHTML).
Bref, c'est comme entre XHTML 1 et HTML 4.01 : ce n'est qu'une histoire de notation. Les balises, les attributs etc, sont identique dans les deux cas.
[^] # Re: ah, la mémoire...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 3 béta 2. Évalué à 2.
[^] # Re: 1 Milliard de sous
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sun rachète MySQL AB. Évalué à 1.
[^] # Re: LTS ou pas
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Ubuntu 8.04 alpha 3, prête à déboguer !. Évalué à 6.
Quant au choix de krita, je ne vois pas en quoi c'est un manque de discernement : je trouve normal d'avoir des logiciels kde/qt dans un environnement kde (meilleure intégration), et je trouve que krita a de moins en moins de choses à envier à gimp (surtout pour un usage "normal").
Bon et puis on peut pas dire que apt-get install ou l'utilisation de adept soit particulièrement compliqué pour installer tes logiciels préférés (non mais).
[^] # Re: great
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal KDE4 is out \o/. Évalué à 2.
s/alsacien/alssacien
[^] # Re: Et pour choisir l'application de son choix ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox et linux. Évalué à 2.
[^] # Re: Objet relationnel
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Jelix 1.0. Évalué à 0.
Je ne sais pas, je ne connais pas JPA :-)
Ceci dit, pour les fichiers XML, il y a des scripts en ligne de commande fourni pour les générer, et pour les DAO en particulier, à partir de la base. (Et ils ne sont pas généré à la volée car il n'est pas toujours possible de tout détecter au niveau du schema selon la base, selon la qualité du schema etc...)
[^] # Re: Et pour choisir l'application de son choix ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox et linux. Évalué à 4.
Prend pas ton cas pour une généralité :-)
Je suis sous KDE depuis des années, j'adore KDE, mais je préfère Firefox à Konqueror... Et j'aimerais bien aussi une meilleure intégration de FF dans Kde...
[^] # Re: Et pourquoi ne pas passer à Subversion ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Nan mais quoi comme gestionnaire de bugs ?. Évalué à 3.
[^] # Re: "Running Gag" inside this post ! (be careful !)
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox et linux. Évalué à 0.
[^] # Re: Et pour choisir l'application de son choix ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox et linux. Évalué à 1.
Pour ce qui est de Firefox/QT, ben... quand il y aura des volontaires ?
Pour des raisons historiques, Gecko utilise GTK. Il y a eu dans le trunk Mozilla la possibilité de remplacer GTK par QT (c'est à dire plus de trace de gtk), mais le problème est que ceux qui avaient fait cette partie de code ne l'ont jamais vraiment maintenu. Ça compilait même plus d'ailleurs à un moment. Ils ont donc fini par virer dans le trunk (et donc FF3) le support QT et les sources qui allaient avec.
Mais bon, si des volontaires veulent s'investir à nouveau sur QT inside FF, c'est toujours possible.
Bizarrement, y a toujours eu des volontaires pour aider au support de GTK dans FF, mais jamais vraiment pour QT...
[^] # Re: oué
Posté par Laurent J (site web personnel, Mastodon) . En réponse au sondage Linuxfr compatible OpenID ?. Évalué à 3.
[^] # Re: Pas le point 2
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Logiciel libre ou communautaire : Ma définition.. Évalué à 2.
Y a pas de raisons qu'un patch soit intégrés après des plombs. Par exemple dans Mozilla, quand tu proposes un patch, et que tu demandes une revue, elle se fait dans les quelques heures ou jours, mais pas des semaines. Et ceci parce qu'il y a des responsables, des reviewers pour telle ou telle partie de code, et que la revue de code fait partie de leurs tâches (le code de mozilla est tellement gros qu'il n'y a personne qui connait suffisement bien *tout* mozilla pour pouvoir faire les reviews de n'importe quel patch).
bref, ton "ça va pas marcher" n'est pas vrai. Ça fonctionne dans de nombreux projets.
>Ça marche avec Wikipedia, ça marche avec KDE
Ouai enfin, la qualité des articles dans wikipedia est très très inégale. Et ils ne sont pas systématiquement toujours relus. Mais à la limite, on s'en fiche un peu, un mauvais article ne met pas en péril le projet. On ne peut pas en dire autant dans un projet informatique comme KDE : du mauvais code peut ajouter des trous de sécurité, des problèmes de stabilité etc... Je trouve donc ça hasardeux de comparer Wikipedia avec un projet informatique.
# Pas le point 2
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Logiciel libre ou communautaire : Ma définition.. Évalué à 3.
Ce n'est pas parce qu'on ne donne pas les clés à tout le monde au dépôt de source que le projet est moins communautaire. Très franchement, je préfère qu'une certaine confiance s'instaure entre les dirigeants d'un projet, et un contributeur, avant de lui donner les clés. Pourquoi ?
- parce que même si on peut annuler des modifs, c'est franchement une perte de temps que de corriger les merdes de contributeurs peu scrupuleux, codant comme des porcs, ou tout simplement débutant. Et dieu sait si le temps nous est particulièrement précieux.
- J'ai pas envie, sur mes projets que les types commit n'importe quoi, des fonctionnalités dans tout les sens, des trucs qui font dévier le projet de ses objectifs, ou encore des trucs inutiles, au risque de mettre en péril le produit même : au niveau stabilité, utilisabilité etc.. (c'est du vecu)
- Si on s'aperçoit qu'un type auquel on vient de donner l'accés, fait du mauvais boulot, c'est encore une perte de temps pour le virer (lui expliquer, tout ça...), et ce n'est jamais agréable pour les deux parties. En tout cas, c'est un risque fort de tuer l'ambiance du projet si le gars en question n'est pas content et qu'il fait des histoires parce qu'on lui a couper son accès. Éviter ce genre de problème, c'est des soucis en moins. Bref, je préfère qu'il y ait une sélection à l'entrée, plutôt que de devoir virer les gens.
- Corollaire : Ne pas donner accès en écriture à tout le monde est un gage d'une certaine qualité, en tout cas d'une qualité du niveau de ce qu'attendent les responsables du projet.
- Je ne vois pas franchement à quoi ça sert de livrer l'accés en écriture si il y a un outils de suivi (bugzilla ou autre) et qu'il est utilisé efficacement : n'importe qui peut faire un checkout, faire sa modif en locale, et proposer un patch dans un ticket. Où est le problème ?
De plus, tu penses qu'un processus de review c'est long et contre-communautaire : moi je dis que l'absence de review est synonyme de code pourri (en tout cas, pourrissement à moyen et long terme, donc de plus en plus dur à maintenir). Les reviews permettent d'une part aux nouveaux venus d'apprendre par leurs erreurs, et d'autre part de faire en sorte que le code commité soit d'un niveau de qualité minimal. Par exemple, dans Mozilla, les patchs, de qui que ce soit (qu'il soit débutant sur le projet ou un vieux de la vieille), sont revues par au moins deux personnes. Et pour un projet d'une telle complexité, c'est pas du superflu.
D'ailleurs, la revue de code est un des fondements des méthodes "agiles" de développement, et garantissent, avec les tests unitaires, d'une qualité **constante**, et en tout cas plus uniforme sur l'ensemble du projet.
Bref, je préfère donner les clés à des contributeurs qui ont montré par leurs contributions passées, qu'ils sont sérieux, qu'ils codent pas trop mal et qu'ils sont actifs.
Il est possible que les devs de KDE donnent accès en écriture à tous, mais je serais vraiment étonné si ils ne mettent pas des droits restreints sur certains répertoires...
Pour conclure, non, restreindre l'accès en écriture au dépôt de source n'est pas une condition pour que le développement soit agréable. Ça n'empêche nullement de coder, de proposer des patchs. Ce qui fait qu'il est agréable de contribuer à un projet, c'est le contact que l'on a avec les devs, c'est le fait qu'il ne soit pas fait n'importe quoi sur le projet, et donc qu'il y ait des objectifs clairs et définis, qu'il y ait un minimum de serieux (sans tombé dans une atmosphère dictatoriale), que les reviewers soient "pédagogiques" genre pas dire, "ton patch il est nul", mais expliquer pourquoi ici ou là ça ne va pas, qu'est ce qu'il est préférable de faire etc. Bref, avoir l'impression qu'on apprend quelque chose, qu'on avance tous ensemble dans la même direction.
Ah oui au fait, en utilisant des dépôts décentralisés, ton point 2 n'a pas lieu d'être... les dépôts centralisés sont has been, surtout pour les gros projets... (même si j'aime bien et j'utilise subversion :-) )
[^] # Re: Firefox 15 dans les bacs
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 3 béta 2. Évalué à 2.
Et des choses qui ne se voient pas : le moteur de rendu a eu des parties refondues pour un meilleur support de CSS, performances accrues, améliorations de la gestion de la mémoire, améliorations dans le support SVG, amélioration de l'accessibilité (ceux qui utilisent des lecteurs d'écrans par ex vont apprécier).
Enfin bref, prend le temps de lire http://www.mozilla.com/en-US/firefox/3.0b2/releasenotes/#wha(...)
Pour tes problèmes de lenteurs : tu as manifestement un problème sur ta machine avec ton système. Les builds de Firefox subissent de manière incessantes des tests de perfs dans tout les sens, sur tout les types de machines courantes (windows, mac, linux...). Si il y avait de tels problèmes sur ces système "normaux", ça serait corrigé aussitôt.
[^] # Re: acid2
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 3 béta 2. Évalué à 1.
https://bugzilla.mozilla.org/show_bug.cgi?id=289480#c179
Pour IE8, il passe effectivement le test acid (avec un nouveau moteur de rendu basé sur le moteur de rendu de MS Office...)
http://blogs.msdn.com/ie/archive/2007/12/19/internet-explore(...)
[^] # Re: ah, la mémoire...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 3 béta 2. Évalué à 1.
[^] # Re: 2 moyens
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Le disque, le loup et le phoque. Évalué à 1.
# Baclé ou pas ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal phpBB3 vient de sortir !. Évalué à 1.
Ouai enfin, je suis dubitatif. Parce que bon, quand je vois qu'ils ont sorti 8 RC avant la finale, je me dis qu'il y a un problème quelque part :
- soit ils ont sorti la RC1 trop tôt, c'est à dire non débuggée et alors ils auraient dû l'appeler beta (pour rappel : RC= release candidate, c'est à dire une version censée être stable, suffisament débuggée, prête donc à être utiliser en prod)
- soit leur code est toujours aussi pourri (il n'y avait qu'à voir le nombre de requête SQL inutiles executée à chaque page dans les versions précédentes)
Enfin bref, 8 RC, pour moi ça ne fait pas sérieux et n'est pas un gage de qualité, et ils ont certainement des progrès à faire au niveau de la prise en compte de la qualité dans leur processus de développement (par exemple, je n'ai pas vu de tests unitaires dans le dépôt CVS).