Fork de django-cors-header

Que faisons nous ?

a marqué ce sujet comme résolu.

Bonjour à tous,

Pour le site nous utilisons une dépendance (pour l'API) django-cors-header qui malheureusement a été délaissée par son auteur.

J'ai fait une PR, contacté l'auteur par email à deux reprises ce dernier mois et aucune nouvelle de sa part. Il ne donne pas signe de vie sur GitHub et n'a pas touché au projet sur les 9 derniers mois.

Nous avons donc décidé de forker le projet afin de pouvoir merger ma PR et supporter Django 1.9 (une des issues prioritaires en ce moment car la version que nous utilisons n'est plus supportée). Nous allons donc pouvoir débloquer ça.

Une question se pose maintenant : ce fork est-il officiel ou officieux ? Pour le moment il est officieux.

Si l'association est d'accord il peut devenir officiel. Cela implique de maintenir le code (qui n'est pas très gros) et de potentiellement bénéficier de PR et de reports de bug. Le travail n'est pas énorme car le code n'est pas très gros. Qu'en pensez-vous ?

+2 -0

Si les devs de ZdS apportent des améliorations et que l'auteur a abandonné le projet, ça me paraît logique de maintenir ce projet et ainsi d'en faire profiter tout le monde, d'autant plus que tu as l'air de dire que ça ne va pas trop augmenter la charge de travail de l'équipe.

Je ne suis pas dev par contre, je n'ai jamais contribué au code du site donc je ne peux que parler sur le principe.

Ca me paraît mieux de forker, officialiser, et assurer la maintenance du projet.

Ca me paraît pas fou comme module, positionner (et vérifier) les bons headers sur des requêtes/réponses HTTP c'est pas la mer à boire. Par contre ça dépend énormément de l'API de Django (et des modèles request/response) s'ils les changent à chaque version par contre ça peut demander du boulot (et du boulot pénible en plus). Là-dessus je ne peux pas m'exprimer, c'est ptet' le seul problème potentiel, si chaque maj de Django casse le projet. M'enfin ça m'étonnerait.

A voir aussi (à horizon plus lointain) ce qui se passe pour ces headers avec http2, et comment Django gère tout ça, m'enfin ça commence à être de la SF.

+0 -0

Oui, c'est facile de forker ça. Modifier la licence vous pouvez aussi mais je trouve que c'est pas cool: vous récupérez un projet avec une licence permissive, qui permet à tout le monde de faire à peu près ce qu'ils veulent, vous faites quelques commits dessus et hop c'est votre projet et vous mettez une licence restrictive dessus, je trouverais ça carrément gonflé et déplacé. On veut pas faire du droit de la propriété intellectuelle mais coder, alors les licences assez longues pour faire pâlir l'intégrale de Bourbaki et qui cassent les pieds des gens avec des restrictions, je pense que c'est pas une bonne idée. En plus, la GPL est contaminante et du coup c'est pas une bonne licence a priori pour un projet de plugin Django. Même Django est sous licence permissive (la licence BSD).

Par contre, vous pouvez (et c'est ce que je ferais) modifier la notice de copyright pour vous y inclure. Ça ressemblerait à ceci:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Original work Copyright (c) 2012 Bidule  
Modified work Copyright 2016 (année où l'auteur n'intervient plus, et où vous êtes le mainteneur du projet) ZdS and contributors

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

J'ai trouvé cette explication ici.

Un autre détail: je pense aussi qu'il faut modifier le nom du projet. django-cors-headers c'était le projet original, vu que vous modifiez le projet et que ce n'est plus l'original vous pouvez l'appeler django-cors par exemple, sous réserve que ce projet n'existe pas déjà. Vous pourriez alors le dire dans le fichier de license, en disant que le projet original est sous licence bidule à tel endroit et que le nouveau projet est sous licence machin.

Oui, c'est facile de forker ça. Modifier la licence vous pouvez aussi mais je trouve que c'est pas cool: vous récupérez un projet avec une licence permissive, qui permet à tout le monde de faire à peu près ce qu'ils veulent, vous faites quelques commits dessus et hop c'est votre projet et vous mettez une licence restrictive dessus, je trouverais ça carrément gonflé et déplacé.

C'est pas du tout ce que je comptais faire, je voulais simplement changer le Copyright 2013 Otto Yiu and other contributors http://ottoyiu.com.

Merci Grimur pour ces détails. Pour le changement de nom on va attendre un peu et voir avec SpaceFox qui prend ce genre de décision. Si c'est le cas il faudra penser à l'uploader sur pypi.

+0 -0

Si l'association est d'accord il peut devenir officiel. Cela implique de maintenir le code (qui n'est pas très gros) et de potentiellement bénéficier de PR et de reports de bug. Le travail n'est pas énorme car le code n'est pas très gros. Qu'en pensez-vous ?

Il faut voir, car supporter officiellement (si on veux faire les choses correctement) signifie :

  • Avoir une façon de gérer les releases différente de ce que l'on a sur le dépot zds-site
  • Assurer la compatibilité des versions supportées par Django (ainsi que le support Python 2 et 3)
  • Faire les maj de doc quand c'est nécessaire
  • Utiliser de l'anglais pour tout

On m'a toujours dis que le projet ZdS n'est développé que dans le but de servir les besoins du site, là on s'orienterait sur un autre objectif à savoir devoir supporter des versions que le site n'utilise pas forcément. Il faut en être conscient si on décide de faire un fork officiel.

Mais mon avis est qu'au vu de nos ressources en termes de dev limités, on devrait se contenter de faire un fork officieux ( zds-cors-middleware ) comme celui de python-zmarkdown et se concentrer sur nos ZEPs qui s'accumulent pas mal.

Tant qu'il n'y a pas de demande particulière, pourquoi se prendre la tête ?

On maintient notre fork dans notre coin en modifiant le readme pour préciser quelle modif on a put faire. Et tant qu'on a pas de demandes supplémentaires on fait pas plus que le minimum.

On est d'accord. Pour le moment j'ai déjà ajouté 1 PR (pour ajouté un outil de check de la qualité du code), j'en ai une que je vais review et j'en ai une à venir. Donc autant dire que ça intéresse des gens. Après, j'ai 2 issues en cours pour des demandes d'améliorations. C'est pas indispensable mais ça peut être sympa. Dans la mesure où ça ne nous concerne pas directement je ne vais pas les traiter en priorité, j'ai d'autres choses de prévues. En revanche j'ai pas mal appris juste en regardant les différentes demandes donc je suis vraiment satisfait d'avoir forké ça.

+3 -0

Bah de toute façon c'est toujours un prob de ressource. Si ça te fait plaisir de le maintenir et de l'améliorer, fait le. Si tu n'as pas le temps, marque en gros dans le readme que l'on fait pas de support dessus, que c'est juste une version très légèrement modifié. Si ça tu as envie de le maintenir, marque le (en mode "nous allons essayer de le maintenir et de le faire évoluer"). Mais c'est à toi de voir. Perso ça ne me gène pas que des membres maintiennent des projets annexes qui sont liés à zds tant que c'est une volonté de leur part (et pas une contrainte).

Good news, au bout de 2 mois le dev a enfin donné signe de vie (mais ne semble toujours pas lire ses mais sur ses 2 adresses). Je vous laisse lire et me dire si pour vous c'est OK, moi ça me va parfaitement.

https://github.com/ottoyiu/django-cors-headers/issues/81#issuecomment-173752930

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte