Bonjour,
> > 1) Quelle est politique à propos de Clearbricks, a-t-on les pleins > > pouvoir sur la branche default, car bien que essentiellement utilisée et > > hébergée (tout comme) par Dotclear, elle n'en fait pas vraiment partie > > et d'autres personnes l'utilisent. > > > > Au moins 2 personnes de ma connaissance l'utilisent pour des projets > complètement étrangers à DC. > > Je pense que le fait que d'autres personnes utilisent clearbricks complique un peu les choses. > Si on venait à faire évoluer CB au delà de la simple "maintenance" (montée > légère de version de PHP) alors je pense qu'il serait bon de maintenir la > version actuelle (0.8) sur une branche dédiée et de poursuivre sur la > branche default (ou 1.0) d'une part et d'en faire la publicité que ceux qui > l'utilisent soient prévenus. > > ça semble logique. > > > 2) L'avantage de Clearbricks est qu'elle fonctionne sur quasi tous les > > serveurs, c'était d'ailleurs son but premier. Le temps de retard qu'elle > > a par rapport aux innovations PHP n'est-elle pas un avantage ? (hormis > > les deprecated comme modifier PCRE \e, mysql vs mysqli, etc) > > > > Le gros avantage de CB est qu'elle est légère et plutôt universelle, ça > contribue à la faible empreinte mémoire de DC et à sa rapidité. > Je ne serai pas aussi catégorique. Par exemple l'exemple donné par Régis que j'ai mis en avant en faisant les tests pour atoum : clearbricks redéfini la fonction hash_hmac car la fonction n'était certainement pas native. Mais entre les deux il n'y a pas photo niveau rapidité. > > Vu de ma paroisse, j'envisagerais de poursuivre une version 1.0 en montant > la version de PHP vers la 5.2 tant que la 2.6 n'est pas sortie, puis de > passer à une version 1.2 et support PHP 5.3, puis 1.4 avec PHP 5.4 au fur > et à mesure de l'élévation de la contrainte de version de PHP pour DC. > > Chaque branche de DC se branchant évidemment sur la version idoine de CB. > > Du coup on continue à faire évoluer. Et que penses-tu de l'idée que j'avais proposé de laisser tomber le sous dépôt et de passer à composer ? Cela impliquerait de légèrement modifié le système de build (4/5 lignes dans le Makefile) mais cela aurait plusieurs avantages : - un peu de visibilité au projet (tiens ils utilisent des outils modernes chez dotclear !!) - plus de commit inutile sur DC du genre "mise à jour de la version de CB" > > > 3) Des messages sont également passés disant "la suite c'est de s'en > > séparer", bon OK je sais que, hum, non. z'en pensez ? > > > > > Et au delà de ce que je disais précédemment on peut aussi envisager de > remplacer complètement CB par ??? et là je vous laisse la parole, n'ayant > pas d'idée particulière à ce sujet. > Sans tests unitaires et fonctionnels c'est du suicide quel que soit l'outil magique que l'on pourrait trouver. > > À tout le moins je pense qu'il serait bon d'essayer de faire en sorte que > DC conserve peu ou prou ses deux avantages (occupation mémoire et > rapidité). > Du coup il faut continuer à le faire évoluer. Nicolas -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
