SUJET :

Hello,
I have published my initial package. As usual, it will stay a few days in my sandbox before moving to the official repo.
I use my branch to fix some issue and the patches have been shared with the project.
I have created a short page on the Wiki in English and French.
en.opensuse.org/XyGrib
fr.opensuse.org/XyGrib
It's already available for 1 click install.
software.opensuse.org/package/xygrib
I guess that I am done for today.
Dominig

I will have to deal with capitalisation to clean the search when I do the official publish.

Hello Dominig,

I took a look at your sandbox and noticed that you have used XyGrib code from the Master branch which is work in progress for release 1.2.2 at some time in the near future. This includes a significant amount of yet untested code changes.

The latest release is version 1.2.0. Please use this version and not development code.

A second issue is that you have hacked the software code and removed an integral feature for checking updates and notification regarding this to the users of XyGrib. This is an important feature as we put heavy value on servicing and supporting our users and you have unilaterally decided to block us from part of our valued connection with our users.

You have also hacked the data files location logic. This will lead to support problems that we will be unable to deal with.

If you wish to change XyGrib you are free to fork it but please offer us the courtesy of identifying the package differently. You should also make it clear that you are the supporter to the software and not identify it with opengribs.org or XyGrib. You will also need to provide a suitable grib server for the fork.

Thank you,
David

dominig écrit: fr.opensuse.org/XyGrib

Bonjour,
Il y a un truc que je ne comprends pas très bien,.
Je croyais que vous vouliez créer un paquet pour l'OS OpenSuse, comme je le faisais avec zyGrib pour l'OS Debian/Ubuntu (j'ai commencé pour XyGrib, mais ce n'est pas encore public, car je souhaite que cela prenne en compte les diverses évolutions, dont certaines sont en cours et pas complètement opérationnelles pour que cela fonctionne sans problème. Il y a également un effort en cours pour les Raspberry Pi, qui n'ont pas les mêmes processeurs, même sil le principal OS est rasbian (une adaptation idoine de debian pour ce joli petit outil utilisé de plus en plus souvent sur les voiliers).
La version actuelle publiée est la version 1.2.0 et vous publiez une version 1.1.0 (et si j'en crois David, elle est construite à partir de la version en développement non encore complètement testée, actuellement numérotée 1.2.2).
Cette discrépance est non seulement de nature à perturber les utilisateurs, mais également la petite équipe de volontaires qui aura toutes les peines du monde à identifier un potentiel problème soulevé par un utilisateur.

Ce n'est pas ainsi que je conçois le travail collaboratif sur de projets sous licence GPL.
Soit on travaille ensemble, on échange, on discute des objectifs des solutions possibles ...
Soit, comme le suggère David, si vous avez d'autres idées et d'autres envies, il n'y a aucun problème pour vous de créer un fork de l'application et la mise en place du serveur qui se charge du travail de backoffice.

Avec zyGrib, cela posait probablement moins de problème dans la mesure où le code source n'était pas partagé dans une forge facilitant le travail collaboratif; les mises à jour déployées ne dépendant que d'une seule personne. Ce n'est plus le cas avec XyGrib, même si l'équipe est petite, elle travaille ensemble tant sur les objectifs, les nouveautés à développer pour répondre aux besoins exprimés des utilisateurs, les solutions techniques à envisager de façon à pouvoir faire le maximum tout en minimisant les contraintes en particulier liées à la diversité des plateformes.
En souhaitant que nous puissions résoudre cette difficulté pour le bénéfice de tous les utilisateurs.

Bonjour,
je passe en Français comme la remarque finale même si je suis plus a l'aide en anglais.

1) GPL

---

La beauté du GPL est qu'il est possible de faire ce que l'on veut avec le code.
Le GPL3 demande de republier. Ce que j'ai fait en mettant mon code sur GitHub et en vous passant mes patch.
J'ai fait mes patch des façon à ce qu'ils ne changent pas le votre mode de fonctionnement existant.

2) Mes modifications

---

Je travaille sur une Distro. Je n'installe pas de code en zone writable par le user space. C'est un principe inviolable.
Mes motifs ne font que mettre en place ce qui est indispensable pour respecter cette règle de sécurité et stabilité.

3) Version

---

Je suis parti de master, parce qu'il faut partir de quelque part. Je suis toujours en sandbox.
J'ai aucun problème à reprendre d'une version dite stable pour la publication dans les repos officielles.

4) accès à votre serveur

---

Vous pouvez en théorie restreindre l'accès à votre serveur mais dans ce cas vous violerez la GPLV3 qui dit que l'utilisateur peut modifier le code si il le veut dans tous les cas. Comme vous partiez de zygrib qui est en GLP V3, c'est pas simple.

5) Nom

---

Si votre marque est déposée, vous pouvez en restreindre l'usage comme bon vous semble. Merci dans ce cas de me le faire savoir.
Pour l'instant je ne vois aucun dépôt de marque sur l'INPI en France ni dans d'autre pays.
OpenSUSE wiki publie les pages dès qu'elles sont faite.

6) Collaboration

---

Je n'ai pas envie de faire un fork mais il me faut une solution de Grib.
Je pensais que mettre en avant votre projet en remplacement de zygrib était intéressant. Si c'est un problème, je referait un package pour zygrib et le problème sera régler.
Je ne mettrais pas en place un soft qui pousse du code en zone user writable et qui n'est pas contrôler et compiler par la Distro.
Même les grands comme Firefox et Google doivent suivre cette règle.
Je n'ai pas de problème à gérer les patch requis pour ce changement même si je préfèrerai les voir intégrer au code avec des #ifdef.

Le fait d'être à plusieurs sur le code n'et pas un problème. Je travaille à temps plein pour Intel Open Source sur Automotive Grade Linux et je collabore pour OpenCPN. Ce sont des projets où il y a pas mal de monde sur le pont.

7) Suite

---

Dite moi si mon modèle vous bloque ou si une collaboration est possible.
Selon votre réponse, je publierai votre code ou une mise à jour de zygrib.


Dominig

Hello,
No problem with english.

2. In the user's space, I only have files that have parameters that are configured by the user to overwrite the default and when compiling deb packages from the git put app in /usr/bin and data in /usr/share/openGribs/XyGrib. (I am not a fun of AppImage, but it helps to concentrate on the main task which is to improve the app for visualisation of weather numerical models).
When directly compiliing from git it goes in /usr/local/ (even in the little script available on the Download page show that).
When deb packaging directly from git it goes in /usr/

4. Server access
zyGrib server was never a public service that can be accessed from requests not using the part of the code of zyGrib. Some have tried to implement automatic download and were locked.
It is the same with XyGrib.

5. Name
No problem if you just compile, but you start to adapt the code... (there are many examples)
And it is not a question of marque déposée, but just a gentleman behavior.

6. Your collaboration is welcome and I also think that it is better to work together.
I do not write in user space, it is a disaster when you have many users, as it is the case for me, even on a small sailing boat, my crew has a user that can only consult sailing data and use sailing app without the possibilty of doing the nice "rm -rf *.*"
And it works perfectly well with the original source code.

For this problem of what is where, if you could improve the code allowing to have the app in /usr/bin (or /usr/local/bin if compile from source) and data in /usr/share/openGribs/XyGrib (or /usr/local/share/openGribs/XyGrib) and to have in $HOME/.config/openGribs/XyGrib including the modified color files found in /usr/local/share/openGribs/XyGrib/data/colors as it seems that some users want to have other color scales.

Personally I prefer distro packages, but for the time being it is above time availabity of the people working regularly on that.