[OSM-talk-fr] OSM en read-only (était : Vélib' Paris)

[Philippe Verdy]

Le 1 avril 2012 19:16, Vincent Pottier <vpottier at gmail.com> a écrit :
> Par contre les "yaka" et "faut-qu'on" sont déplacés.

Tu as vu ça où dans mon commentaire les "yaka faux-cons" ? J'ai
exprimé mon point de vue car justement je crois que la Fondation a
pris un trop grand risque, et finalement pris une position sur la base
de l'autorieté et la responsabilité de quelques-uns en oubliant
totalement la communauté.

En plus une telle migration de type « big bang » (on arrête tout, on
croise les doigts, et on recommence) est intenable. C'est en plus un
gaspillage de ressources qui va coûter bien plus cher que prévu.

Parfaitement inutile, risqué, ruineux. Il a déjà eu pour effet de
diviser la communauté qui soutenait le projet. Et mis en exergue une
prise de pouvoir inconsidérée par la Fondation et ses quelques
administrateurs « autorisés » désignés par elle qui vont dans ces 4
jours prendre des décisions sacrificielles dans l'urgence (juste pour
tenir le délai annoncé de 4 jours), pas forcément les bonnes, qu'il
sera difficile d'inverser ensuite.

Rien que le fait de supprimer plus de 1,5% des données (uniquement
pour le changement de licence), plus des données qui ne seront pas
passées pendant la migration du serveur, est une perte considérable,
qui n'a aucune équivalent dans la vie passée du projet (des
contributeurs ont été exclus et bloqués pour BEAUCOUP moins que ça).

Je n'aime pas du tout cette précipitation. Je ne connais plus AUCUN
projet de cette taille qui fasse de telles migrations de type Big
Bang. Tout le monde sait (sauf la Fondation) que c'est ultra-risqué et
ruineux. Toute bonne migration se fait par petites étapes qui passent
presque inaperçues, et dont les problèmes éventuels restent encore
limitées, mesurables, et réparables sans interrompre le projet, et qui
conservait encore la possibilité d'appeler la communauté à aider à les
résoudre (chose totalement impossible dans cet arrêt où tout revient à
une poignée d'administrateurs surchargés, qui n'ont pas le temps de
discuter et prendront en fin de compte des décisions irrévocables tous
seuls...)

J'ai bien peut que quand le service redémarrera, la base sera beaucoup
plus « nettoyée » que ce qui a été annoncé, si elle redémarre sur le
nouveau serveur, ou bien que finalement cela échoue et qu'on se
retrouve dans 4 jours avec toujours l'ancien serveur et une nouvelle
planification de 4 jours pour retenter le coup la semaine suivante !
(Bref deux fois le prix).

C'est en ce sens que je trouve ce coup-là une vraie partie de «
roulette russe. » Qui ne sera pas sans dégâts, déjà visibles...
puisque cela a déjà abouti à un fork immédiat du projet (en fait non
motivé par l'arrêt technique du serveur pour en monter un autre, ce
qui n'était pas du tout nécessaire, mais par un changement de licence,
mais le fait est que FOSM a maintenant plus de données qu'OSM, et va
continuer à en avoir plus, notamment dans certains pays comme la
Pologne ou l'Allemagne).

De même il était parfaitement possible de gérer dans la base de
données des conditions de licence différentes selon les utilisateurs
et sources, en stockant ces données dans des couches séparées.
d'ailleurs plus que le changement de licence pour les utilisateurs,
c'est la migration forcée des sources qui pose un réel problème de
survie du projet, d'autant plus que la nouvelle licence unique n'a
encore passé aucun test de résistance légale, contrairement à Creative
Commons (même si son étendue reste limitée). Je ne voayis aucun
problème à avoir deux licences simultanées pour justement que le
projet puisse résister à une attaque légale externe.

En revanche l'arrêt du service pendant 4 jours est une décision
totalement unilatérale, c'est même une attaque interne (par la
Fondation elle-même) contre la communauté qui l'a soutenue jusqu'à
présent. Car je ne vois pas à quel titre on a autorisé certains
administrateurs désignés uniquement par elle de pouvoir supprimer
toute donnée valide qui poserait problème pour tenir les délais de
migration annoncés.

Et on le voit bien : la migration est commencée, mais on n'a
strictement aucun suivi de ce qui se passe, car justement ces
administrateurs n'ont pas le temps de communiquer. On n'a aucune idée
des problèmes survenus (et il doit y en avoir, forcément !, c'est
inévitable) et des décisions prises dans l'urgence.

On ne sait pas si les décisions prises sur une partie seront
réversibles et si on aura même la possibilité de repérer ce qui
manque, ou comment restaurer les données réparées. Ce sera la surprise
totale, il va falloir comparer les dumps avant et après la migration,
avec des outils très lourds de comparaison.

Le premier dump fait sur le nouveau serveur et le dernier sur l'ancien
serveur, seront à scruter précisément. On risque de passer des
semaines ou des mois à recoller les morceaux, et finalement même ne
jamais pouvoir les recoller puisque cela demanderait plus de travail,
avec les outils actuels, que de retracer de zéro les objets
manquants...