Le leadership fort de Canonical, je pense que c'est pas un souci en soi. La question, c'est comment il se traduit. Si ça se traduit par "Canonical fait tout le taf, mais on a rien à redire", ça passe sans souci. Si ça se traduit par "Canonical ne garde que sa platforme en tête et envoie chier le tête du monde avec des pratiques qui n'aident pas à la collaboration", ça coince.
Exemple, Unity, qui a du mal à se faire packager sur les autres distributions parce qu'il faut des patchs de partout, parce que Canonical change de techno sans arrêt, et parce que du coup, tu dois faire suivre la stack.
A coté de ça, bzr s'est retrouvé dans tout les distributions sans souci et très vite. Ou des choses comme simple-scan, voir même upstart (adopté par Fedora et RHEL, et je sais que les autres étaient aussi en train d'envisager l'intégration).
De même, reprendre la bibliothèque de résolution de zypper pour dnf, qui va à terme remplacer yum sur Fedora. Ou Mono, et divers applications comme banshee, tomboy, le fork d'openoffice (go-ooo), c'était des technologies très fortement dirigé par Novell, et en dehors d'une suspicion juridique pour mono chez RH, la plupart des distros n'ont pas eu de souci à intégrer (ni même gnome à ce niveau, même si les gens ont ralés sur C# car trop lourd, comme python ou js)
Pour le CLA, c'est plus simple, y a déjà le cas par le passé.
A la fin du meeting, on était tous d'accord pour dire "le software center, c'est bien", mais tout les gens payés étaient aussi d'accord pour dire "nos employeurs vont sans doute refuser qu'on signe le CLA de Canonical car il est déséquilibré".
L'idée étant de porter le software center pour utiliser package-kit.
Donc dans l'ordre, ce qui a été fait, c'est d'expliquer au dev du dit soft (présent ce jour) le souci du CLA. Il été non seulement parfaitement compris le souci, mais il était déjà au courant. Et il avait déjà tenté de faire changer les choses.
Si le CLA n'était pas retiré, les 2 options sont "on forke", et "on refait de 0".
Cad une refonte de 0. refonte de 0 soit parce que le python n'était pas adapté (trop lourd, pas assez rapide), soit parce que les buts de gnome-software sont plus ambitieux, comme indiqué sur http://blogs.gnome.org/hughsie/2013/03/05/gnome-software-overall-plan/
J'ai aussi vu lors d'une conf l'idée d'avoir directement une intégration entre différent systéèe de paquets, genre gem, pip, npm (python, ruby, node), via un système de plugin. Comme ça, les gens (comme moi) qui veulent que les paquets de la distro peuvent, et ceux qui veulent autre chose, ils peuvent aussi.
Et pour précision, le software center, dans sa forme moderne, ça date grosso modo de 2009. Donc il a fallu 1 à 2 ans pour que les gens se disent "ça semble bien, comment on peut collaborer".
Donc il a fallu une paire d'années avant que tout se déroule et que les gens se rallient si le projet est intéressant. Ça peut aller un peu plus vite si tu impliques les gens dés le début (cf adoption de systemd).
[^] # Re: MS est un devellopeur ?
Posté par Misc (site web personnel) . En réponse au journal Kubunteros, réfléchissez!. Évalué à 8.
Le leadership fort de Canonical, je pense que c'est pas un souci en soi. La question, c'est comment il se traduit. Si ça se traduit par "Canonical fait tout le taf, mais on a rien à redire", ça passe sans souci. Si ça se traduit par "Canonical ne garde que sa platforme en tête et envoie chier le tête du monde avec des pratiques qui n'aident pas à la collaboration", ça coince.
Exemple, Unity, qui a du mal à se faire packager sur les autres distributions parce qu'il faut des patchs de partout, parce que Canonical change de techno sans arrêt, et parce que du coup, tu dois faire suivre la stack.
A coté de ça, bzr s'est retrouvé dans tout les distributions sans souci et très vite. Ou des choses comme simple-scan, voir même upstart (adopté par Fedora et RHEL, et je sais que les autres étaient aussi en train d'envisager l'intégration).
De même, reprendre la bibliothèque de résolution de zypper pour dnf, qui va à terme remplacer yum sur Fedora. Ou Mono, et divers applications comme banshee, tomboy, le fork d'openoffice (go-ooo), c'était des technologies très fortement dirigé par Novell, et en dehors d'une suspicion juridique pour mono chez RH, la plupart des distros n'ont pas eu de souci à intégrer (ni même gnome à ce niveau, même si les gens ont ralés sur C# car trop lourd, comme python ou js)
Pour le CLA, c'est plus simple, y a déjà le cas par le passé.
J'ai participé à ça:
https://blog.mageia.org/en/2011/01/26/back-from-application-installer-meeting/
A la fin du meeting, on était tous d'accord pour dire "le software center, c'est bien", mais tout les gens payés étaient aussi d'accord pour dire "nos employeurs vont sans doute refuser qu'on signe le CLA de Canonical car il est déséquilibré".
L'idée étant de porter le software center pour utiliser package-kit.
Donc dans l'ordre, ce qui a été fait, c'est d'expliquer au dev du dit soft (présent ce jour) le souci du CLA. Il été non seulement parfaitement compris le souci, mais il était déjà au courant. Et il avait déjà tenté de faire changer les choses.
Si le CLA n'était pas retiré, les 2 options sont "on forke", et "on refait de 0".
1 an après la réunion, ça a donné ça :
http://blog.tenstral.net/2012/08/gsoc-appstream-final-report.html
(ie un fork du soft pour le CLA dans le cadre du GSOC)
2 ans après, ça donne ça:
https://fedoraproject.org/wiki/Changes/AppInstaller
https://wiki.gnome.org/Design/Apps/Software
Cad une refonte de 0. refonte de 0 soit parce que le python n'était pas adapté (trop lourd, pas assez rapide), soit parce que les buts de gnome-software sont plus ambitieux, comme indiqué sur http://blogs.gnome.org/hughsie/2013/03/05/gnome-software-overall-plan/
J'ai aussi vu lors d'une conf l'idée d'avoir directement une intégration entre différent systéèe de paquets, genre gem, pip, npm (python, ruby, node), via un système de plugin. Comme ça, les gens (comme moi) qui veulent que les paquets de la distro peuvent, et ceux qui veulent autre chose, ils peuvent aussi.
Et pour précision, le software center, dans sa forme moderne, ça date grosso modo de 2009. Donc il a fallu 1 à 2 ans pour que les gens se disent "ça semble bien, comment on peut collaborer".
Donc il a fallu une paire d'années avant que tout se déroule et que les gens se rallient si le projet est intéressant. Ça peut aller un peu plus vite si tu impliques les gens dés le début (cf adoption de systemd).