Quelques explications pour ceux qui ignore l'histoire: Mark "Ubuntu" Shuttleworth a proposé à l'aKademy 2007 que tous les projets upstream (KDE, amsn, VLC, Gnome....) aient un cycle de release synchronisé de 6 mois pour faciliter le travail des distribution. En gros ce que Neije propose.
J'avoue avoir été sur le moment séduit par l'idée, principalement pour l'impact marketing et le coté pratique d'avoir une distrib le jour de la sortie de KDE, firefox, OOo....
mais à la réflexion et apres quelques débat à l'akademy (et apres) c'est en fait vraiment une fausse bonne idée.
Déjà, d'un point de vue marketing, la concentration de nouveautés de la distrib "X" contenant les dernier Gnome/KDE/OOo/amsn/VLC/aMule/Apache/........ va réduire comme peau de chagrin la communication de chaque projet libre. Si on prend KDE par exemple, il n'y aurait plus une news complete sur linuxfr+clubic+pcinpact+ ... mais seulement 2 lignes noyés sur une news de distrib. Et dans le temps cela implique moins de couverture médiatique pour chacun des projets.... 2 lignes tous les 6 mois. Difficile de faire rêver et d'attirer des utilisateurs et des contributeurs avec ça. Pour le marketing du libre au global, cela implique des trous d'air de 6 mois.
Mais le plus gros problème est coté développement. Un projet libre est un très subtil équilibre. Entre les phases innovation/dev/test/livraison, les vies de chacun, les outils utilisés (la vie de KDE est lié à celle de QT, celle de Firefox à celle de Gecko...).
Certains projets trouvent leur équilibre à 6mois, 8mois, 1an, ... d'autres sont continus. Il y a la souplesse nécessaire aussi à un projet de retarder une release de 15jours ou 3 semaines en cas de soucis.
Synchroniser tout le monde, cela veut dire par exemple qu'un projet va passer de 6mois de dev, 1 mois de freeze, 1 mois de beta/RC/bugfixe, à un système 4,2mois de dev, 3semaines de beta, 1mois de bugfixe (incompressible). Au final, moins de dev, d'innovation, et peut-etre meme moins de développeurs aussi car la proportion fun(dev)/barbant(bugfixe) sera moins attrayante. Bref, c'est tres mauvais à long terme pour la vie du projet, mais également pour les distributions elle même.
[^] # Re: Dommage : mauvais timing
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse à la dépêche Test d'openSUSE 11.1. Évalué à 9.
J'avoue avoir été sur le moment séduit par l'idée, principalement pour l'impact marketing et le coté pratique d'avoir une distrib le jour de la sortie de KDE, firefox, OOo....
mais à la réflexion et apres quelques débat à l'akademy (et apres) c'est en fait vraiment une fausse bonne idée.
Déjà, d'un point de vue marketing, la concentration de nouveautés de la distrib "X" contenant les dernier Gnome/KDE/OOo/amsn/VLC/aMule/Apache/........ va réduire comme peau de chagrin la communication de chaque projet libre. Si on prend KDE par exemple, il n'y aurait plus une news complete sur linuxfr+clubic+pcinpact+ ... mais seulement 2 lignes noyés sur une news de distrib. Et dans le temps cela implique moins de couverture médiatique pour chacun des projets.... 2 lignes tous les 6 mois. Difficile de faire rêver et d'attirer des utilisateurs et des contributeurs avec ça. Pour le marketing du libre au global, cela implique des trous d'air de 6 mois.
Mais le plus gros problème est coté développement. Un projet libre est un très subtil équilibre. Entre les phases innovation/dev/test/livraison, les vies de chacun, les outils utilisés (la vie de KDE est lié à celle de QT, celle de Firefox à celle de Gecko...).
Certains projets trouvent leur équilibre à 6mois, 8mois, 1an, ... d'autres sont continus. Il y a la souplesse nécessaire aussi à un projet de retarder une release de 15jours ou 3 semaines en cas de soucis.
Synchroniser tout le monde, cela veut dire par exemple qu'un projet va passer de 6mois de dev, 1 mois de freeze, 1 mois de beta/RC/bugfixe, à un système 4,2mois de dev, 3semaines de beta, 1mois de bugfixe (incompressible). Au final, moins de dev, d'innovation, et peut-etre meme moins de développeurs aussi car la proportion fun(dev)/barbant(bugfixe) sera moins attrayante. Bref, c'est tres mauvais à long terme pour la vie du projet, mais également pour les distributions elle même.
Beaucoup d'inconvénients pour peu d'avantages.