Je pense qu'il serait idiot de dupliquer les efforts de développement, surtout sur un tel projet qui ne compte déjà que peu de contributeurs. C'est la raison pour laquelle je ne propose que des corrections de bugs dans KompoZer. S'il y avait un moyen d'intégrer des patches dans la version officielle de Nvu, la situation serait évidemment plus simple pour tout le monde (développeurs et utilisateurs).
Le code de l'éditeur HTML est complexe, il y a peu de gens aptes à le faire évoluer, et personne d'autre que Daniel pour en assurer la direction (pour autant que je sache). Par contre, c'est une base facilement extensible...
Je pense donc que la plupart des "killer features" devraient être développées sous forme d'extensions, au moins dans un premier temps. Ça permettrait à Daniel de se concentrer sur l'éditeur HTML, tout en laissant le soin à d'autres de développer ou d'améliorer les fonctionnalités connexes : un gestionnaire de sites, un nettoyeur de balises, un éditeur CSS, etc. Ces fonctionnalités sont développables par des développeurs du dimanche, contrairement au coeur de l'application.
De même, une option qui me semble envisageable pour la maintenance de l'application (Nvu, KompoZer, Composer2) serait de pré-installer une extension "service pack" qui contiendrait des corrections mineures (= celles qu'on peut faire en chrome). La mise à jour d'une extension est très simple, ce qui permettrait de les tester et de les déployer rapidement, sans avoir à refaire une release, pour (éventuellement) les intégrer dans la version suivante.
Bref, je pense qu'un projet de cette envergure serait plus facile à maintenir s'il était moins monolithique. Je rêve tout haut...
[^] # Re: Orgueil VS en-faire-profiter-a-tous
Posté par Fabien Cazenave . En réponse à la dépêche Nvu, Kompozer et Mozilla Composer. Évalué à 6.
Le code de l'éditeur HTML est complexe, il y a peu de gens aptes à le faire évoluer, et personne d'autre que Daniel pour en assurer la direction (pour autant que je sache). Par contre, c'est une base facilement extensible...
Je pense donc que la plupart des "killer features" devraient être développées sous forme d'extensions, au moins dans un premier temps. Ça permettrait à Daniel de se concentrer sur l'éditeur HTML, tout en laissant le soin à d'autres de développer ou d'améliorer les fonctionnalités connexes : un gestionnaire de sites, un nettoyeur de balises, un éditeur CSS, etc. Ces fonctionnalités sont développables par des développeurs du dimanche, contrairement au coeur de l'application.
De même, une option qui me semble envisageable pour la maintenance de l'application (Nvu, KompoZer, Composer2) serait de pré-installer une extension "service pack" qui contiendrait des corrections mineures (= celles qu'on peut faire en chrome). La mise à jour d'une extension est très simple, ce qui permettrait de les tester et de les déployer rapidement, sans avoir à refaire une release, pour (éventuellement) les intégrer dans la version suivante.
Bref, je pense qu'un projet de cette envergure serait plus facile à maintenir s'il était moins monolithique. Je rêve tout haut...