Le Mercredi 6 Juillet 2005 15:21, Vincent Fretin a écrit :
> J'ai beaucoup réfléchi à cette idée de fusion.
> Je le dit tout de suite, si fusion il y a, ce n'est pas seulement
> "intégration de mokoshi et splinux dans nasgaia et suppression de
> octoz". Cette idée là ne me va pas du tout.
> Comme l'as dit gontran sur irc "nous avons tous notre vécu par rapport
> au projet sur lequel on boss"
> C'est pour cela que c'est difficile de se mettre d'accord sur une
> fusion, on veut garder les outils que l'on a développé. C'est normal.

Oui, c'est tout à fait normal :-)
Je suis allé voir la page wiki qui tu as indiqué sur Opkg et Hedgar. Et, sauf 
si je me trompe, il y a beaucoup de fonctionnalités prévues, mais qui ne sont 
encore qu'à l'état d'idées, notamment pour Hedgar (mais peut-être que la page 
n'est plus à jour ?). Ce qui me fait dire cela est qu'il est beaucoup dit : 
« on pourra faire ceci ... on pourra faire cela ... » et qu'il y a pas mal de 
choses dans la section TODO. Il reste donc pas mal de développement à 
faire :-) . 

En ce qui concerne Nasgaia, nous avons déjà un équivalent à Opkg et Hedgar 
parfaitement utilisable : Ncooker et Napt de la version 1.0.1 de Nasgaia. Il 
reste bien sûr des choses à faire, mais nos deux outils possèdent déjà de 
nombreuses fonctionnalités : utilisation de paquets sources (les NBUILDs, 
équivalent à SRPM) ou de paquets binaires (les NBAs pour installer 
directement les applications sans avoir à les compiler), gestion des 
dépendances (à améliorer mais fonctionnel), préservation des fichiers de 
configuration (dans /etc entre autre), désinstallation des paquets 
NBUILDs/NBAs, possibilité de recompiler une appli déjà installée sur le 
système (depuis un NBUILD ou un NBA, peu importe) pour l'adapter au mieux à 
la configuration matérielle, possibilité de définir des « providers » de 
paquets avec différentes sources : CD, disque dur, Internet ... mise à jour 
de la liste des paquets disponibles sur les providers ...

Historiquement, Nasgaia est une distribution qui a déjà sorti plusieurs 
versions bêta, suivies d'une version stable 1.0, puis d'une version de 
correction 1.0.1. Cette succession de releases à contribué à affirmer 
l'existence de notre Projet et à l'accréditer au yeux de la Communauté Open 
Source.

Tout ça pour dire que, si de votre coté vous avez du mal à abandonner le 
travail que vous avez déjà fait, vous pouvez imaginer à quel point c'est 
encore plus difficile pour nous vu l'état d'avancement de notre distribution, 
résultat d'une quantité de travail encore plus importante :-)

Celles et ceux qui ont rejoints Nasgaia ont été attiré principalement par deux 
choses : son Esprit/Philosophie (partagé par votre projet apparemment) et 
l'originalité de son gestionnaire de paquets. Nos gestionnaires de paquets 
respectifs ont leurs qualités, mais de ce que j'en ai vu, ils ont des 
approches et des implémentations différentes. Pour ne citer qu'un exemple, 
pour la nouvelle version de Ncooker, nous avons décidé d'abandonner le 
classement des paquets par arborescence, car cela ne nous paraît plus être 
une bonne méthode, pour attribuer à chaque paquet des méta-informations 
(Troves nodes) qui caractérisent son domaine d'application. Si j'ai bien 
compris, Hegdar a besoin de cette notion d'arborescence ... Il ne s'agit là 
que d'un point parmi de nombreux autres. Et je me demande si cela vaut 
réellement le coup de chercher à fusionner nos outils ? Étant le développeur 
principal de Ncooker, je ne te cacherai pas que j'aurai beaucoup de mal à 
abandonner ses fondements :-)  Je reconnais que je manque assurément 
d'objectivité dans mes propos et que mon amour propre y est certainement pour 
beaucoup. Mais je pense que tu me comprends car je devine la même chose de 
ton coté :-) 

Ceci étant dit, je pense que nous avons beaucoup en commun en ce qui concerne 
les aspects philosophiques. Et plutôt que de chercher à fusionner, je pense 
comme Riri qu'une collaboration serait plus bénéfique à nos deux projets. 
Réaliser des échanges d'idées et en discuter, expliquer comment nous avons 
mis en place certaines fonctionnalités dans nos outils respectifs ... tout 
cela peut apporter beaucoup, sachant que chaque projet implémente ces idées à 
sa manière.
Maintenant, les participants sont également libres de travailler sur le projet 
qui leur convient le mieux, voir les deux, ce qui permettrait d'entretenir 
d'autant plus efficacement cette collaboration :-)

Voilà, je ne sais pas ce que tu en penses ? mais ça me parait être un bon 
compromis : chacun peut continuer à développer ses outils tout en profitant 
de la richesse et des idées de l'ensemble des participants.


Amicalement,
Gontran

Répondre à