search

datagouv / schema.data.gouv.fr

Schémas de données ouvertes sur des formats réglementaires ou non
https://schema.data.gouv.fr
MIT License
41 stars 26 forks source link

Un dépôt par schéma ou un seul pour tous ? #4

Closed abulte closed 5 years ago

abulte commented 5 years ago

Il nous faut choisir entre :

Les deux solutions ont des avantages et des inconvénients. Nous sommes plutôt partis au départ sur un seul dépôt afin d'en faciliter la maintenance. Parlons ici des différents arguments pour ou contre avec tous les acteurs concernés.

Re https://github.com/etalab/schema.data.gouv.fr/issues/2#issuecomment-457519619.

AntoineAugusti commented 5 years ago

Je suis pas de @etalab/datagouv, mais voici mon avis.

En faveur d'un seul dépôt, au moins pour le moment :

🍿

noirbizarre commented 5 years ago

Je suis plutôt pour un seul dépôt, quite à avoir des sous-modules git pour ceux qui existe déjà à l'exterieur. Cela permet:

Pour le versionning de schema, il est recommandé d'avoir des URLs du type http://schema.data.gouv.fr/irve/1.0/ ce qui est facile à faire avec une copie de répertoire (tout en gardant l'ancienne version intacte), git n'apportera pas grand chose à ce niveau là.

L'approche monorepo fonctionne très bien avec les sous-modules si certains éprouvent le besoin d'héberger le dépôt ailleurs (avec bien sûr les contraintes de dispo qui vont avec).

Par contre, il serait opportun de formaliser le format préconisé pour un schema.

Ex:

├── autre
│   └── 1.0
│       └── README.md
├── irve
│   ├── 1.0
│   │   ├── README.md
│   │   └── schema.json
│   └── 2.0
│       ├── README.md
│       └── schema.json
└── plf
    └── 1.0
        ├── README.md
        └── schema.json

Sur ce modèle, chaque répertoire peut être un sous-module si c'est vraiment nécessaire (ça entraîne quand même de la complexité de gestion puisqu'une PR mergée sur un sous-module entraîne forcement une PR ici pour mettre à jour le sous-module).

abulte commented 5 years ago

ping @ColinMaudry @pierredittgen

johanricher commented 5 years ago

A l'heure actuelle, Validata ne gère pas plusieurs schémas par dépôt. Plus d'infos :

noirbizarre commented 5 years ago

À en croire le code et le fichier schema.toml, il n'y a pas d'incompatibilité avec le monorepo si les schemas sont publiés sur des URLs. D'ailleurs ce schema.html référence bien des URLs et non des dépôts git. Est-ce que je me trompe ?

Qu'est-ce qui l'empecherai d'avoir https://schema.data.gouv.fr/irve/1.0/schema.json ?

johanricher commented 5 years ago

Les numéros de version de chaque schéma sont dans l'URL (tag). Dans le système actuel de Validata, garder plusieurs schémas dans un même dépôt impliquerait donc d'incrémenter leurs numéros en même temps ce qui n'est pas souhaitable.

noirbizarre commented 5 years ago

J'espère pour la pérennité des formats de données qu'on aura pas de version patchées sur les schema: ça tue un peu le principe des schemas si on a 365 versions par schema, non?

Si effectivement c'est le fonctionnement que vous souhaitez retenir, rien n'empêche pour ces schemas là de faire un sous-module, mais ça veut dire qu'il faudra pour chaque changement:

Pour ajouter un argument en faveur du monorepo, c'est en général le fonctionnement qui est retenu pour la gestion des schemas et specs car contrairement au versions logicielle (ce pourquoi git a été conçu), les schemas et les specs sont fait pour une durée de vie infinie et donc les versions vivent en parallèle:

Mais surtout, le problème que je vois dans le système de branche c'est que les URLs dépendent de l'implémentation de l'interface web du dépôt git, ce qui ne fonctionne que sur github et gitlab, mais pas sur un dépôt git raw. Si github et gitlab change l'URL de l'accès raw (déjà arrivé au moins une fois), on perd les URLs des schémas et ce définitivement. Il me semble d'ailleurs que ces URLs ne sont pas compatible CORS pour éviter qu'elle soient référencées dans des clients comme si c'était un CDN, donc utilisation dans un navigateur proscrite. À l'inverse, on a un contrôle total sur les URLs publiées par un site statiques. On peut changer d'hébergeur, d'outils de build... le tout sans impact.

noirbizarre commented 5 years ago

Confirmé: github force le Content-Type à text/plain sur raw.githubusercontent.com ce qui pose problème pour l'utilisation depuis un browser puisque depuis 2013, github renvoie aussi X-Content-Type-Options: nosniff (et d'autres entêtes CSP) ce qui empêche toute interprétation typée d'un fichier (problématique pour le JSON par exemple) La solution de contournement était jusqu'à présent d'utiliser rawgit, mais comme marque sur leur page d'accueil, ils coupent le service au mois d'Octobre

ColinMaudry commented 5 years ago

Je suis plutôt convaincu par les arguments de @noirbizarre pour la gestion des schémas, ce qui ne signifie pas que le schémas doivent forcément être servis directement depuis des URL en http://github.com ou http://raw.githubusercontent.com/.

On peut publier le tout sur un site statique, ou via un schema.data.gouv.fr..github.io, qui ait une arborescence, des README, des conventions de nommage, des landing page... qui rendent le tout très clair et ergonomique pour les cas d'usage... qu'il serait bien d'identifier (ex : Validata).

Bref structuration du dépôt git != structuration pour publication.

cbenz commented 5 years ago

À en croire le code et le fichier schema.toml, il n'y a pas d'incompatibilité avec le monorepo si les schemas sont publiés sur des URLs.

Tout à fait. La question initiale que nous nous posions côté validata était plutôt : comment un outil (tel que validata) peut-il accéder à une version précédente du schéma afin de permettre à ses utilisateurs de le tester.

Avec des répertoires différents par version du schéma, validata sera content.

Je comprends les arguments en faveur du monorepo et du site statique. Je suis convaincu moi aussi que peu de releases c'est mieux pour les schémas afin de garantir leur stabilité. En contrepartie, tenir une version de rodage plus longtemps, faire intervenir plusieurs avis avant release, me paraît sain.

Mon but n'est pas de convaincre d'utiliser un repo par schéma, mais plutôt d'inciter à trouver une solution pour permettre d'accéder aux versions précédentes.

En attendant, l'outil validata peut très bien référencer la branche "master" du schéma, ou même un "commit_id" spécifique.

Pour info voici le raisonnent qui nous a conduit à adopter 1 repo par schéma :

jdesboeufs commented 5 years ago

Un avantage de la solution 1 repo par schéma est de permettre d'ajouter des collaborateurs extérieurs sur chaque répo facilement, en gardant une gouvernance globale légère.

Mais c'est une avantage de riche.

noirbizarre commented 5 years ago

Je comprends totalement le raisonnement derrière le 1 schéma par repo et ça fait totalement sens dans la phase de création du schéma de pouvoir itérer sur des version mineures 0.x ou patch en 0.x.x. Une fois la version 1.0 atteinte, les URLs stables deviennent un prérequis.

Du coup on peut imaginer 2 fonctionnements différents sur un même dépôt fédérateur:

Dans les 2 cas le principe reste le même, avec une logique par dépôt ou par répertoire, et permet d'être compatible avec la méthode décrite par les liens fournis par @johanricher .

De cette manière, pour chaque schéma, l'équipe en qui travaille dessus est libre de choisir ce qui lui convient pour le démarrage.

Le point important pour moi c'est le côté fédération/point d'entrée unique pour les usagers.

Dans un premier temps si le site statique n'est pas vraiment nécessaire, il peut être intéressant de déjà publier le contenu du dépôt sur l'URL schema.data.gouv.fr de façon à ce que les schémas soient accessibles sur des URLs durables.

ColinMaudry commented 5 years ago

@noirbizarre On en a pas beaucoup parlé, mais c'est un point crucial : la structure d'URL choisie doit être pérenne, solide.

Donc les schémas doivent être publiés sur un domaine sur lequel on a la main, pour pouvoir, un jour, si nécessaire, faire des redirections.

johanricher commented 5 years ago

Mais c'est une avantage de riche.

Disposer d'un dépôt par schéma ne me paraît pas être un caprice au regard des moyens que cela nécessite (zéro euro supplémentaire).

Le point important pour moi c'est le côté fédération/point d'entrée unique pour les usagers.

De toute façon les dépôts Git ne seront jamais le point d'entrée pour les utilisateurs finaux de ces schémas, qui seront plutôt sur des outils tels que l'hypothétique site statique schema.data.gouv.fr ou Validata. En l'occurence, ses usagers n'ont pas besoin de savoir où se trouve le schéma qu'ils utilisent (voire même ce qu'est réellement un schéma). Ni quand ils vérifient la conformité d'un fichier, ni quand ils consultent la documentation.

Ce système, qui est de fait décentralisé, et où chacun doit pouvoir contribuer librement au code, me paraît adapté au multi-repo, qui porte par ailleurs d'autres avantages au niveau de la gouvernance, des permissions d'accès en écriture et de la gestion des tickets.

Par exemple il peut devenir souhaitable dans le futur d'inviter sur un dépôt des contributeurs extérieurs qui auront des droits pour maintenir un schéma, par exemple une personne référente avec une connaissance métier. Dans ce cas de figure il ne serait pas possible de donner des droits de mainteneur sur un seul schéma, au sein d'un dépôt qui en comporterait plusieurs.

De fait ce dépôt est une exception puisque les 5 schémas actuellement sur Validata, et les 3 prochains portés par OpenDataFrance (équipements, catalogue, point d'eau incendie), existeront chacun dans leur propre dépôt et il me semble que cela devrait perdurer.

ColinMaudry commented 5 years ago

@johanricher Alors il y a certes l'usage de la simple validation de fichier qui ne nécessite pas une utilisation de Git ou l'accès au code source du schéma, mais il y a aussi des informaticien.nes qui voudront contribuer, voir la source, documenter, et qui sait, traduire.

Les utilisateurs finaux de schémas constituant la norme nationale d'un pays de 65 millions de personnes n'est pas une population homogène. Aujourd'hui on est au tout début de cette pratique des schémas de données nationaux, tâchons de rester accessibles à tous et toutes celleux que ça pourrait intéresser.

johanricher commented 5 years ago

il y a aussi des informaticien.nes qui voudront contribuer, voir la source, documenter, et qui sait, traduire.

Les sources (dépôts des schémas) sont évidemment indiquées de façon relativement proéminente sur Validata à travers la documentation. Pour ce cas précis que tu soulèves, qui est un besoin important, le fait d'avoir un schéma par dépôt n'engendre pas de problème particulier.

noirbizarre commented 5 years ago

Par contre, une chose que je n'avais pas noté, mais le 1 dépôt par schéma permet de gérer plus facilement des tests différents et indépendant par schéma.

CharlesNepote commented 5 years ago

Je suis favorable à la solution 1 dépôt par schéma qui refète une vision "métier" :

Entendons-nous bien, je ne suis pas contre une (ou plusieurs) valorisation(s) centralisée(s) des schémas, au contraire. Mais dans le respect des acteurs, des complémentarités, de la diversité des métiers et des initiatives.

thom4parisot commented 5 years ago

J'ai l'impression qu'il y a 2 discussions qui s'entremêlent :

  1. l'écriture — contribution et maintenance.
    Les souhaits que je comprends : un schéma est facile à trouver, un schéma est facile à modifier, les schémas sont versionnés (plusieurs versions cohabitent)
  2. la lecture — pérenne et fiable.
    Les souhaits que je comprends : ce que j'ai aujourd'hui, je l'aurai demain ; si quelque chose est déplacé, je suis redirigé·e.

La lecture peut être garantie par l'outillage. L'outillage peut être changé.

L'écriture est ce qui va consommer le plus de temps et d'énergie par les personnes qui y contribuent. Les choses se rangent. Marie Kondo a bien démontré qu'on peut ranger autrement quand ça devient le bordel.

Je rajoute un autre exemple de schémas versionnés sur GitHub : plusieurs schémas, plusieurs versions, même repo, 227 personnes y ont contribué. 📦 https://github.com/SchemaStore/schemastore/tree/master/src/schemas

1 dépôt par schéma facilite les questions de gouvernance des schémas

Pourquoi ça facilite la gouvernance ?

les participants à la discussion sur tel ou tel schéma/repo peuvent très variés et appartenir à des métiers très différents ; ils n'auront pas envie d'avoir le détail de la discussion de tous les schémas

L'avis de ces personnes est consigné quelque part ? Sinon c'est de la spéculation.

1 dépôt par schéma facilite l'intégration de schémas extérieurs à l'organisation : il devient plus facile de créer un site de valorisation des schémas à partir de travaux d'autres organisations ; aujourd'hui il existe peu d'acteurs qui produisent des schémas mais qu'en sera-t-il demain ?

Bah, les schémas extérieurs peuvent être sur des dépôts extérieurs (comme c'est le cas aujourd'hui). Si d'autres acteurs produisent des schémas, la question de l'organisation se posera à nouveau, les choses ne sont pas scellées dans le béton.

mais le 1 dépôt par schéma permet de gérer plus facilement des tests différents et indépendant par schéma.

Si l'organisation est "1 chemin d'accès différent par version de schéma", y'a pas de problème pour des tests indépendants ?

CharlesNepote commented 5 years ago

Dans l'exemple que tu donnes, de nombreux schémas du catalogue sont justement hébergés sur leurs propres repos :

Pourquoi ça facilite la gouvernance ?

La réponse me paraît être dans ta question : si chaque schéma a son repo, on ne perd pas trop de temps à discutailler tel ou tel point ; chaque propriétaire/mainteneur de schéma gère son schéma comme il l'entend. Ça n'empèche pas de fédérer les schémas comme dans l'exemple que tu donnes.

les participants à la discussion sur tel ou tel schéma/repo peuvent très variés et appartenir à des métiers très différents ; ils n'auront pas envie d'avoir le détail de la discussion de tous les schémas

L'avis de ces personnes est consigné quelque part ? Sinon c'est de la spéculation.

Il me semble que les spécialistes de borne de recharge vont se sentir un peu perdus lorsqu'ils vont se retrouver sur un dépôt où leur sujet représentera une toute partie des discussions/issues/commits. C'est en tous cas mon avis en tant que rédacteur d'un schéma (et travaillant sur autre actuellement). Et ça semble aussi être le cas d'Open Data France, qui a choisi un repo par schéma.

Tirer à pile ou face est aussi une option raisonnable, j'entends les arguments pro-centralisation.

flacombe commented 5 years ago

Bonsoir à tous Ma première contribution à ce dépôt, je suis François (@ InfosReseaux sur Twitter). C'est la présentation d'Axel de lundi à l'Afigéo qui m'a incité à pousser la porte

La réponse me paraît être dans ta question : si chaque schéma a son repo, on ne perd pas trop de temps à discutailler tel ou tel point ; chaque propriétaire/mainteneur de schéma gère son schéma comme il l'entend. Ça n’empêche pas de fédérer les schémas comme dans l'exemple que tu donnes.

Bien que ce ne soit pas le but premier, il peut être aussi intéressant de mutualiser ces schémas, pour éviter les silos et faciliter la réutilisation des concepts. Je travaille actuellement beaucoup avec les schémas Avro (json), qui peuvent s'inclure les uns dans les autres, ce qui est commode lorsqu'on manipule des notions complexes et qu'on ne veut pas repartir de zéro à chaque fois (penser aux Légo). Difficile d'en tirer parti entre dépôts indépendants. Sans vous parler d'OpenStreetMap, projet où l'espace de nom est commun.

Je suis clairement en faveur du mono-dépôt, sans quoi les cloisons qui nous posent tellement de problèmes aujourd'hui resteront. Cela n'empêche pas par ailleurs de forker et d'avoir des discussions précises sans faire de bruit particulier. Il me semble important de contribuer à un pot commun, mon propos ne concerne que l'écriture. La lecture pouvant/devant être traitée via une plateforme autre que git.

AntoineAugusti commented 5 years ago

Merci à tous pour vos commentaires. Nous avons retenu la solution un schéma par dépôt.