[QGIS-fr-user] Avis sur la plateforme de report de bug de QGIS

Bonjour,

Il y a en ce moment un sujet sur la liste développeurs de QGIS qui pourrait faire l’objet d’un vote dans les prochains jours donc, comme promis, je l’évoque ici afin d’avoir les avis du groupe sur le sujet: la migration du dépôt de signalement de bugs de QGIS.

Le lien vers la discussion en anglais est http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Last-call-for-switching-to-github-issue-tracker-td5349599.html

Une tentative de résumé : Il semble que le site https://issues.qgis.org n’est pas des plus pratiques/(plus adapté?) aux besoins de QGIS et qu’une meilleure intégration consisterait à migrer vers https://github.com/qgis/QGIS.

D’autres alternatives de dépôt plus ouvert ont aussi été évoquées dans la discussion.

En attendant de savoir clairement quelles vont être les options sur lesquelles il faudra se prononcer, il serait intéressant de partager ici (ou dans la discussion d’origine) votre expérience/impression de l’outil actuel de report de bugs (si vous en êtes utilisateur - régulier ou très occasionnel): prise en mains, navigation, recherche, ce que vous appréciez, ce qui manquerait…

Cordialement,
Harrissou

Bonjour à tous,

merci Harrissou de remonter le sujet et de consulter la communauté avant le vote.

Essayons de poser les enjeux et les fonctionnalités attendues d’un gestionnaire du tickets idéal pour le projet QGIS.

Pour les demandeurs:

  • Permettre de saisir simplement des tickets d’anomalie ou de demande d’évolution

  • Permettre de rechercher efficacement (vite et juste) des tickets similaires pour éviter le doublonnage de tickets. Une bonne indexation par les moteurs de recherche externe est un point critique.

  • Permettre d’inclure simplement des illustrations, images animées

  • Permettre de ‘pinguer’ facilement quelqu’un pour l’inviter à la discussion

  • Avoir un système d’authentification unifié avec l’OSGEO pour éviter la démultiplication des mots de passe, profils, identifants, etc…

  • Permettre de tagguer des caractéristiques (type de demande, catégorie, plateforme impactées, version cible etc…)

Pour les gestionnaires du tracker:

  • Permettre de gérer des catégories et d’assigner automatiquement un ou plusieurs responsables pour affiner le statut du ticket

  • sauvegarder des requêtes type

  • exporter / importer des tickets, les PJ, illustrations et tous les commentaires pour pouvoir changer de plateforme au besoin

  • Suivre l’avancement des tâches (tableau kanban par exemple)

  • Limiter les tâches de maintenance serveur (hébergement, maintenance, gestion d’urgence)

···

Le 19 janvier 2018 à 11:41, DelazJ <delazj@gmail.com> a écrit :

Bonjour,

Il y a en ce moment un sujet sur la liste développeurs de QGIS qui pourrait faire l’objet d’un vote dans les prochains jours donc, comme promis, je l’évoque ici afin d’avoir les avis du groupe sur le sujet: la migration du dépôt de signalement de bugs de QGIS.

Le lien vers la discussion en anglais est http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Last-call-for-switching-to-github-issue-tracker-td5349599.html

Une tentative de résumé : Il semble que le site https://issues.qgis.org n’est pas des plus pratiques/(plus adapté?) aux besoins de QGIS et qu’une meilleure intégration consisterait à migrer vers https://github.com/qgis/QGIS.

D’autres alternatives de dépôt plus ouvert ont aussi été évoquées dans la discussion.

En attendant de savoir clairement quelles vont être les options sur lesquelles il faudra se prononcer, il serait intéressant de partager ici (ou dans la discussion d’origine) votre expérience/impression de l’outil actuel de report de bugs (si vous en êtes utilisateur - régulier ou très occasionnel): prise en mains, navigation, recherche, ce que vous appréciez, ce qui manquerait…

Cordialement,
Harrissou


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Salut,

Je crois que Régis n’a rien oublié :slight_smile: J’adhère à son analyse

Pour l’anecdote, j’ajouterai juste que je suis toujours un peu surpris de constater l’importance d’usage, dans les projets Open Source, d’outils propriétaires comme github ou de matériels issus de constructeurs à la politique commerciale pas vraiment ouverte comme les MACs.

Et une question : Quid de gogs/gitea ?

A bientôt.

jm

···

Le 19/01/2018 à 14:52, Régis Haubourg a écrit :

Bonjour à tous,

merci Harrissou de remonter le sujet et de consulter la communauté avant le vote.

Essayons de poser les enjeux et les fonctionnalités attendues d’un gestionnaire du tickets idéal pour le projet QGIS.

Pour les demandeurs:

  • Permettre de saisir simplement des tickets d’anomalie ou de demande d’évolution

  • Permettre de rechercher efficacement (vite et juste) des tickets similaires pour éviter le doublonnage de tickets. Une bonne indexation par les moteurs de recherche externe est un point critique.

  • Permettre d’inclure simplement des illustrations, images animées

  • Permettre de ‘pinguer’ facilement quelqu’un pour l’inviter à la discussion

  • Avoir un système d’authentification unifié avec l’OSGEO pour éviter la démultiplication des mots de passe, profils, identifants, etc…

  • Permettre de tagguer des caractéristiques (type de demande, catégorie, plateforme impactées, version cible etc…)

Pour les gestionnaires du tracker:

  • Permettre de gérer des catégories et d’assigner automatiquement un ou plusieurs responsables pour affiner le statut du ticket

  • sauvegarder des requêtes type

  • exporter / importer des tickets, les PJ, illustrations et tous les commentaires pour pouvoir changer de plateforme au besoin

  • Suivre l’avancement des tâches (tableau kanban par exemple)

  • Limiter les tâches de maintenance serveur (hébergement, maintenance, gestion d’urgence)

Pour les développeurs:

  • être efficacement lié au système d’hébergement du code source

  • être notifié / pouvoir notifier activement quelqu’un

  • garder le lien entre un numero de ticket, une pull request et le ticket.

  • automatiser un maximum la fermeture de ticket avec des mots clés type “Fix #1755

  • avoir un système fiable et robuste d’intégration continue couplé

Pour les financeurs:

  • garder une référence unique et stable dans le temps

  • assurer un espace unique de discussion entre utilisateurs, développeurs, et commanditaires

Pour la communauté OSGEO:

  • Choisir un outil non propriétaire et nous laissant maître de nos données

  • Eviter la dispersion des outils de l’infrastructure OSGEO

Sans oublier quelques facteurs externes, comme le bruit généré par la difficulté à obtenir un login OSGEO, en lien avec le système de “mantra” antispam que nous avons dû mettre en place pour éviter les attaques de spam. Le système est lourd humainement, pas simple à comprendre, et constitue un frein évitable, mais pour l’instant, aucune solution antispam automatique efficace n’a été trouvée.

N’hésitez pas à compléter si j’en oublie, mais il n’y a actuellement pas d’outil parfait pour toutes ces exigences.

En résumé très rapide, ce que je peux dire sur les outils en lice:

- Redmine:

  • l’outil actuel, très paramètrable, hébergé par QGIS, avec de nombreuses possibilité d’adaptation.

  • Conception ancienne, peu couplé aux outils de gestion de code (mais couplé quand même)

  • Recherche lourde, pas très efficace, indexation google perfectible

  • Open source et maitrise totale de nos données

  • Un peu de boulot de gestion des machines (on a eu quelques pannes par moment)

  • Outil découplé des infrastructures OSGEO, avec une situation inconfortable permettant à des utilisateurs de se logguer sans login osgeo, et donc sans faire comprendre que tous les outils FOSS4G sont un tout indissociable.

  • GitHub:

- Héberge le code actuel

  • un presque monopole de facto

  • de très bonnes fonctionnalités sociales

  • Propriétaire gratuit pour l’open source

  • outil propriétaire avec des API limitées pour importer / exporter les tickets

  • Exploite TravisCI pour l’intégration continue, mais c’est pas le mieux (on a souvent des soucis)

  • Assez limité sur la gestion des tickets, paas de catégorie, gestion de projet kanban

  • pas mal d’outils tierces sur le “market place” type huboard par exemple

- Gitlab :

  • Un clone 100 % Open Source de GitHub, soit hébergé, soit hébergeable sur les QGIS ou OSGEO

  • Evolution très rapide, stable, réactif aux demandes

  • A notre goût chez Oslandia, infra d’intégration continue solide.

Et enfin en conduite de projet, c’est toujours une bonne idée de pas tout changer à la fois !

Voilà pour l’information nécessaire pour éclairer le débat :slight_smile:

Le 19 janvier 2018 à 11:41, DelazJ <delazj@gmail.com> a écrit :

Bonjour,

Il y a en ce moment un sujet sur la liste développeurs de QGIS qui pourrait faire l’objet d’un vote dans les prochains jours donc, comme promis, je l’évoque ici afin d’avoir les avis du groupe sur le sujet: la migration du dépôt de signalement de bugs de QGIS.

Le lien vers la discussion en anglais est http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Last-call-for-switching-to-github-issue-tracker-td5349599.html

Une tentative de résumé : Il semble que le site https://issues.qgis.org n’est pas des plus pratiques/(plus adapté?) aux besoins de QGIS et qu’une meilleure intégration consisterait à migrer vers https://github.com/qgis/QGIS.

D’autres alternatives de dépôt plus ouvert ont aussi été évoquées dans la discussion.

En attendant de savoir clairement quelles vont être les options sur lesquelles il faudra se prononcer, il serait intéressant de partager ici (ou dans la discussion d’origine) votre expérience/impression de l’outil actuel de report de bugs (si vous en êtes utilisateur - régulier ou très occasionnel): prise en mains, navigation, recherche, ce que vous appréciez, ce qui manquerait…

Cordialement,
Harrissou


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)

Bonjour à tous

Merci à Régis pour ce propos qui permet effectivement de replacer plus clairement les attendus des uns et des autres selon leur profil (et sensibilité) sur ce que serait une plateforme idéale.

···

Le 24 janvier 2018 à 08:54, Jean-Marie Arsac <jmarsac@azimut.fr> a écrit :

Salut,

Je crois que Régis n’a rien oublié :slight_smile: J’adhère à son analyse

Pour l’anecdote, j’ajouterai juste que je suis toujours un peu surpris de constater l’importance d’usage, dans les projets Open Source, d’outils propriétaires comme github ou de matériels issus de constructeurs à la politique commerciale pas vraiment ouverte comme les MACs.

Certains parleront de principe de réalité; à titre perso, je ne pense pas que cela rende très lisible le discours sur l’Open Source, surtout lorsque des alternatives communautaires peuvent émerger.

Et une question : Quid de gogs/gitea ?

Aucune idée. Je t’avoue que les alternatives à GH n’ont pas tellement été évoquées.

Pour revenir au sujet principal, L’idée ici était donc de savoir, au regard de votre profil, si https://issues.qgis.org/projects/qgis répond bien à votre besoin (facile à prendre en mains ou pas, quelle(s) amélioration(s) possible(s)…) mais faute de retours…

Pour info, un vote vient d’être mis en place pour décider si on devait abandonner la plateforme actuelle pour migrer sur Github pour tout nouveau signalement de bugs ou nouvelle demande de fonctionnalités (https://www.loomio.org/d/cDwCmhsG/proposal-to-shift-bug-issue-tracking-work-to-github-issues-for-qgis-3x-). La période de vote prend fin lundi à l’aube donc le vote du groupe FR sera issu de ceux qui se seront exprimés d’ici samedi minuit.

Géomatiquement,

Harrissou

A bientôt.

jm

Le 19/01/2018 à 14:52, Régis Haubourg a écrit :

Bonjour à tous,

merci Harrissou de remonter le sujet et de consulter la communauté avant le vote.

Essayons de poser les enjeux et les fonctionnalités attendues d’un gestionnaire du tickets idéal pour le projet QGIS.

Pour les demandeurs:

  • Permettre de saisir simplement des tickets d’anomalie ou de demande d’évolution

  • Permettre de rechercher efficacement (vite et juste) des tickets similaires pour éviter le doublonnage de tickets. Une bonne indexation par les moteurs de recherche externe est un point critique.

  • Permettre d’inclure simplement des illustrations, images animées

  • Permettre de ‘pinguer’ facilement quelqu’un pour l’inviter à la discussion

  • Avoir un système d’authentification unifié avec l’OSGEO pour éviter la démultiplication des mots de passe, profils, identifants, etc…

  • Permettre de tagguer des caractéristiques (type de demande, catégorie, plateforme impactées, version cible etc…)

Pour les gestionnaires du tracker:

  • Permettre de gérer des catégories et d’assigner automatiquement un ou plusieurs responsables pour affiner le statut du ticket

  • sauvegarder des requêtes type

  • exporter / importer des tickets, les PJ, illustrations et tous les commentaires pour pouvoir changer de plateforme au besoin

  • Suivre l’avancement des tâches (tableau kanban par exemple)

  • Limiter les tâches de maintenance serveur (hébergement, maintenance, gestion d’urgence)

Pour les développeurs:

  • être efficacement lié au système d’hébergement du code source

  • être notifié / pouvoir notifier activement quelqu’un

  • garder le lien entre un numero de ticket, une pull request et le ticket.

  • automatiser un maximum la fermeture de ticket avec des mots clés type “Fix #1755

  • avoir un système fiable et robuste d’intégration continue couplé

Pour les financeurs:

  • garder une référence unique et stable dans le temps

  • assurer un espace unique de discussion entre utilisateurs, développeurs, et commanditaires

Pour la communauté OSGEO:

  • Choisir un outil non propriétaire et nous laissant maître de nos données

  • Eviter la dispersion des outils de l’infrastructure OSGEO

Sans oublier quelques facteurs externes, comme le bruit généré par la difficulté à obtenir un login OSGEO, en lien avec le système de “mantra” antispam que nous avons dû mettre en place pour éviter les attaques de spam. Le système est lourd humainement, pas simple à comprendre, et constitue un frein évitable, mais pour l’instant, aucune solution antispam automatique efficace n’a été trouvée.

N’hésitez pas à compléter si j’en oublie, mais il n’y a actuellement pas d’outil parfait pour toutes ces exigences.

En résumé très rapide, ce que je peux dire sur les outils en lice:

- Redmine:

  • l’outil actuel, très paramètrable, hébergé par QGIS, avec de nombreuses possibilité d’adaptation.

  • Conception ancienne, peu couplé aux outils de gestion de code (mais couplé quand même)

  • Recherche lourde, pas très efficace, indexation google perfectible

  • Open source et maitrise totale de nos données

  • Un peu de boulot de gestion des machines (on a eu quelques pannes par moment)

  • Outil découplé des infrastructures OSGEO, avec une situation inconfortable permettant à des utilisateurs de se logguer sans login osgeo, et donc sans faire comprendre que tous les outils FOSS4G sont un tout indissociable.

  • GitHub:

- Héberge le code actuel

  • un presque monopole de facto

  • de très bonnes fonctionnalités sociales

  • Propriétaire gratuit pour l’open source

  • outil propriétaire avec des API limitées pour importer / exporter les tickets

  • Exploite TravisCI pour l’intégration continue, mais c’est pas le mieux (on a souvent des soucis)

  • Assez limité sur la gestion des tickets, paas de catégorie, gestion de projet kanban

  • pas mal d’outils tierces sur le “market place” type huboard par exemple

- Gitlab :

  • Un clone 100 % Open Source de GitHub, soit hébergé, soit hébergeable sur les QGIS ou OSGEO

  • Evolution très rapide, stable, réactif aux demandes

  • A notre goût chez Oslandia, infra d’intégration continue solide.

Et enfin en conduite de projet, c’est toujours une bonne idée de pas tout changer à la fois !

Voilà pour l’information nécessaire pour éclairer le débat :slight_smile:

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Le 19 janvier 2018 à 11:41, DelazJ <delazj@gmail.com> a écrit :

Bonjour,

Il y a en ce moment un sujet sur la liste développeurs de QGIS qui pourrait faire l’objet d’un vote dans les prochains jours donc, comme promis, je l’évoque ici afin d’avoir les avis du groupe sur le sujet: la migration du dépôt de signalement de bugs de QGIS.

Le lien vers la discussion en anglais est http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Last-call-for-switching-to-github-issue-tracker-td5349599.html

Une tentative de résumé : Il semble que le site https://issues.qgis.org n’est pas des plus pratiques/(plus adapté?) aux besoins de QGIS et qu’une meilleure intégration consisterait à migrer vers https://github.com/qgis/QGIS.

D’autres alternatives de dépôt plus ouvert ont aussi été évoquées dans la discussion.

En attendant de savoir clairement quelles vont être les options sur lesquelles il faudra se prononcer, il serait intéressant de partager ici (ou dans la discussion d’origine) votre expérience/impression de l’outil actuel de report de bugs (si vous en êtes utilisateur - régulier ou très occasionnel): prise en mains, navigation, recherche, ce que vous appréciez, ce qui manquerait…

Cordialement,
Harrissou


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Bonjour à tous,

Coté utilisateur le redmine bien que surement imparfait nous convient.
j’ai une position assez proche du QGIS Italy user group.

Cordialement,

···

FERRATON Alain
Ministère de la Transition écologique et solidaire (MTES)
SG/SPSSI/CPII/DOO
Chef du groupe Expertise Technique
02.40.12.84.08

Le 30/01/2018 à 10:49, “> DelazJ (par Internet, dépôt qgis-fr-user-bounces@lists.osgeo.org)” a écrit :

Bonjour à tous

Merci à Régis pour ce propos qui permet effectivement de replacer plus clairement les attendus des uns et des autres selon leur profil (et sensibilité) sur ce que serait une plateforme idéale.

Le 24 janvier 2018 à 08:54, Jean-Marie Arsac <jmarsac@azimut.fr> a écrit :

Salut,

Je crois que Régis n’a rien oublié :slight_smile: J’adhère à son analyse

Pour l’anecdote, j’ajouterai juste que je suis toujours un peu surpris de constater l’importance d’usage, dans les projets Open Source, d’outils propriétaires comme github ou de matériels issus de constructeurs à la politique commerciale pas vraiment ouverte comme les MACs.

Certains parleront de principe de réalité; à titre perso, je ne pense pas que cela rende très lisible le discours sur l’Open Source, surtout lorsque des alternatives communautaires peuvent émerger.

Et une question : Quid de gogs/gitea ?

Aucune idée. Je t’avoue que les alternatives à GH n’ont pas tellement été évoquées.

Pour revenir au sujet principal, L’idée ici était donc de savoir, au regard de votre profil, si https://issues.qgis.org/projects/qgis répond bien à votre besoin (facile à prendre en mains ou pas, quelle(s) amélioration(s) possible(s)…) mais faute de retours…

Pour info, un vote vient d’être mis en place pour décider si on devait abandonner la plateforme actuelle pour migrer sur Github pour tout nouveau signalement de bugs ou nouvelle demande de fonctionnalités (https://www.loomio.org/d/cDwCmhsG/proposal-to-shift-bug-issue-tracking-work-to-github-issues-for-qgis-3x-). La période de vote prend fin lundi à l’aube donc le vote du groupe FR sera issu de ceux qui se seront exprimés d’ici samedi minuit.

Géomatiquement,

Harrissou

A bientôt.

jm

Le 19/01/2018 à 14:52, Régis Haubourg a écrit :

Bonjour à tous,

merci Harrissou de remonter le sujet et de consulter la communauté avant le vote.

Essayons de poser les enjeux et les fonctionnalités attendues d’un gestionnaire du tickets idéal pour le projet QGIS.

Pour les demandeurs:

  • Permettre de saisir simplement des tickets d’anomalie ou de demande d’évolution

  • Permettre de rechercher efficacement (vite et juste) des tickets similaires pour éviter le doublonnage de tickets. Une bonne indexation par les moteurs de recherche externe est un point critique.

  • Permettre d’inclure simplement des illustrations, images animées

  • Permettre de ‘pinguer’ facilement quelqu’un pour l’inviter à la discussion

  • Avoir un système d’authentification unifié avec l’OSGEO pour éviter la démultiplication des mots de passe, profils, identifants, etc…

  • Permettre de tagguer des caractéristiques (type de demande, catégorie, plateforme impactées, version cible etc…)

Pour les gestionnaires du tracker:

  • Permettre de gérer des catégories et d’assigner automatiquement un ou plusieurs responsables pour affiner le statut du ticket

  • sauvegarder des requêtes type

  • exporter / importer des tickets, les PJ, illustrations et tous les commentaires pour pouvoir changer de plateforme au besoin

  • Suivre l’avancement des tâches (tableau kanban par exemple)

  • Limiter les tâches de maintenance serveur (hébergement, maintenance, gestion d’urgence)

Pour les développeurs:

  • être efficacement lié au système d’hébergement du code source

  • être notifié / pouvoir notifier activement quelqu’un

  • garder le lien entre un numero de ticket, une pull request et le ticket.

  • automatiser un maximum la fermeture de ticket avec des mots clés type “Fix #1755

  • avoir un système fiable et robuste d’intégration continue couplé

Pour les financeurs:

  • garder une référence unique et stable dans le temps

  • assurer un espace unique de discussion entre utilisateurs, développeurs, et commanditaires

Pour la communauté OSGEO:

  • Choisir un outil non propriétaire et nous laissant maître de nos données

  • Eviter la dispersion des outils de l’infrastructure OSGEO

Sans oublier quelques facteurs externes, comme le bruit généré par la difficulté à obtenir un login OSGEO, en lien avec le système de “mantra” antispam que nous avons dû mettre en place pour éviter les attaques de spam. Le système est lourd humainement, pas simple à comprendre, et constitue un frein évitable, mais pour l’instant, aucune solution antispam automatique efficace n’a été trouvée.

N’hésitez pas à compléter si j’en oublie, mais il n’y a actuellement pas d’outil parfait pour toutes ces exigences.

En résumé très rapide, ce que je peux dire sur les outils en lice:

- Redmine:

  • l’outil actuel, très paramètrable, hébergé par QGIS, avec de nombreuses possibilité d’adaptation.

  • Conception ancienne, peu couplé aux outils de gestion de code (mais couplé quand même)

  • Recherche lourde, pas très efficace, indexation google perfectible

  • Open source et maitrise totale de nos données

  • Un peu de boulot de gestion des machines (on a eu quelques pannes par moment)

  • Outil découplé des infrastructures OSGEO, avec une situation inconfortable permettant à des utilisateurs de se logguer sans login osgeo, et donc sans faire comprendre que tous les outils FOSS4G sont un tout indissociable.

  • GitHub:

- Héberge le code actuel

  • un presque monopole de facto

  • de très bonnes fonctionnalités sociales

  • Propriétaire gratuit pour l’open source

  • outil propriétaire avec des API limitées pour importer / exporter les tickets

  • Exploite TravisCI pour l’intégration continue, mais c’est pas le mieux (on a souvent des soucis)

  • Assez limité sur la gestion des tickets, paas de catégorie, gestion de projet kanban

  • pas mal d’outils tierces sur le “market place” type huboard par exemple

- Gitlab :

  • Un clone 100 % Open Source de GitHub, soit hébergé, soit hébergeable sur les QGIS ou OSGEO

  • Evolution très rapide, stable, réactif aux demandes

  • A notre goût chez Oslandia, infra d’intégration continue solide.

Et enfin en conduite de projet, c’est toujours une bonne idée de pas tout changer à la fois !

Voilà pour l’information nécessaire pour éclairer le débat :slight_smile:

Le 19 janvier 2018 à 11:41, DelazJ <delazj@gmail.com> a écrit :

Bonjour,

Il y a en ce moment un sujet sur la liste développeurs de QGIS qui pourrait faire l’objet d’un vote dans les prochains jours donc, comme promis, je l’évoque ici afin d’avoir les avis du groupe sur le sujet: la migration du dépôt de signalement de bugs de QGIS.

Le lien vers la discussion en anglais est http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Last-call-for-switching-to-github-issue-tracker-td5349599.html

Une tentative de résumé : Il semble que le site https://issues.qgis.org n’est pas des plus pratiques/(plus adapté?) aux besoins de QGIS et qu’une meilleure intégration consisterait à migrer vers https://github.com/qgis/QGIS.

D’autres alternatives de dépôt plus ouvert ont aussi été évoquées dans la discussion.

En attendant de savoir clairement quelles vont être les options sur lesquelles il faudra se prononcer, il serait intéressant de partager ici (ou dans la discussion d’origine) votre expérience/impression de l’outil actuel de report de bugs (si vous en êtes utilisateur - régulier ou très occasionnel): prise en mains, navigation, recherche, ce que vous appréciez, ce qui manquerait…

Cordialement,
Harrissou


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)

_______________________________________________ QGIS-fr-user mailing list QGIS-fr-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)

C’est noté, Alain. Merci.

Harrissou

···

Le 30 janvier 2018 à 11:08, FERRATON Alain (Chef de groupe) - SG/SPSSI/CPII/DOO/ET <Alain.Ferraton@developpement-durable.gouv.fr> a écrit :

Bonjour à tous,

Coté utilisateur le redmine bien que surement imparfait nous convient.
j’ai une position assez proche du QGIS Italy user group.

Cordialement,

FERRATON Alain
Ministère de la Transition écologique et solidaire (MTES)
SG/SPSSI/CPII/DOO
Chef du groupe Expertise Technique
02.40.12.84.08

Le 30/01/2018 à 10:49, “> DelazJ (par Internet, dépôt qgis-fr-user-bounces@lists.osgeo.org)” a écrit :

Bonjour à tous

Merci à Régis pour ce propos qui permet effectivement de replacer plus clairement les attendus des uns et des autres selon leur profil (et sensibilité) sur ce que serait une plateforme idéale.

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Le 24 janvier 2018 à 08:54, Jean-Marie Arsac <jmarsac@azimut.fr> a écrit :

Salut,

Je crois que Régis n’a rien oublié :slight_smile: J’adhère à son analyse

Pour l’anecdote, j’ajouterai juste que je suis toujours un peu surpris de constater l’importance d’usage, dans les projets Open Source, d’outils propriétaires comme github ou de matériels issus de constructeurs à la politique commerciale pas vraiment ouverte comme les MACs.

Certains parleront de principe de réalité; à titre perso, je ne pense pas que cela rende très lisible le discours sur l’Open Source, surtout lorsque des alternatives communautaires peuvent émerger.

Et une question : Quid de gogs/gitea ?

Aucune idée. Je t’avoue que les alternatives à GH n’ont pas tellement été évoquées.

Pour revenir au sujet principal, L’idée ici était donc de savoir, au regard de votre profil, si https://issues.qgis.org/projects/qgis répond bien à votre besoin (facile à prendre en mains ou pas, quelle(s) amélioration(s) possible(s)…) mais faute de retours…

Pour info, un vote vient d’être mis en place pour décider si on devait abandonner la plateforme actuelle pour migrer sur Github pour tout nouveau signalement de bugs ou nouvelle demande de fonctionnalités (https://www.loomio.org/d/cDwCmhsG/proposal-to-shift-bug-issue-tracking-work-to-github-issues-for-qgis-3x-). La période de vote prend fin lundi à l’aube donc le vote du groupe FR sera issu de ceux qui se seront exprimés d’ici samedi minuit.

Géomatiquement,

Harrissou

A bientôt.

jm

Le 19/01/2018 à 14:52, Régis Haubourg a écrit :

Bonjour à tous,

merci Harrissou de remonter le sujet et de consulter la communauté avant le vote.

Essayons de poser les enjeux et les fonctionnalités attendues d’un gestionnaire du tickets idéal pour le projet QGIS.

Pour les demandeurs:

  • Permettre de saisir simplement des tickets d’anomalie ou de demande d’évolution

  • Permettre de rechercher efficacement (vite et juste) des tickets similaires pour éviter le doublonnage de tickets. Une bonne indexation par les moteurs de recherche externe est un point critique.

  • Permettre d’inclure simplement des illustrations, images animées

  • Permettre de ‘pinguer’ facilement quelqu’un pour l’inviter à la discussion

  • Avoir un système d’authentification unifié avec l’OSGEO pour éviter la démultiplication des mots de passe, profils, identifants, etc…

  • Permettre de tagguer des caractéristiques (type de demande, catégorie, plateforme impactées, version cible etc…)

Pour les gestionnaires du tracker:

  • Permettre de gérer des catégories et d’assigner automatiquement un ou plusieurs responsables pour affiner le statut du ticket

  • sauvegarder des requêtes type

  • exporter / importer des tickets, les PJ, illustrations et tous les commentaires pour pouvoir changer de plateforme au besoin

  • Suivre l’avancement des tâches (tableau kanban par exemple)

  • Limiter les tâches de maintenance serveur (hébergement, maintenance, gestion d’urgence)

Pour les développeurs:

  • être efficacement lié au système d’hébergement du code source

  • être notifié / pouvoir notifier activement quelqu’un

  • garder le lien entre un numero de ticket, une pull request et le ticket.

  • automatiser un maximum la fermeture de ticket avec des mots clés type “Fix #1755

  • avoir un système fiable et robuste d’intégration continue couplé

Pour les financeurs:

  • garder une référence unique et stable dans le temps

  • assurer un espace unique de discussion entre utilisateurs, développeurs, et commanditaires

Pour la communauté OSGEO:

  • Choisir un outil non propriétaire et nous laissant maître de nos données

  • Eviter la dispersion des outils de l’infrastructure OSGEO

Sans oublier quelques facteurs externes, comme le bruit généré par la difficulté à obtenir un login OSGEO, en lien avec le système de “mantra” antispam que nous avons dû mettre en place pour éviter les attaques de spam. Le système est lourd humainement, pas simple à comprendre, et constitue un frein évitable, mais pour l’instant, aucune solution antispam automatique efficace n’a été trouvée.

N’hésitez pas à compléter si j’en oublie, mais il n’y a actuellement pas d’outil parfait pour toutes ces exigences.

En résumé très rapide, ce que je peux dire sur les outils en lice:

- Redmine:

  • l’outil actuel, très paramètrable, hébergé par QGIS, avec de nombreuses possibilité d’adaptation.

  • Conception ancienne, peu couplé aux outils de gestion de code (mais couplé quand même)

  • Recherche lourde, pas très efficace, indexation google perfectible

  • Open source et maitrise totale de nos données

  • Un peu de boulot de gestion des machines (on a eu quelques pannes par moment)

  • Outil découplé des infrastructures OSGEO, avec une situation inconfortable permettant à des utilisateurs de se logguer sans login osgeo, et donc sans faire comprendre que tous les outils FOSS4G sont un tout indissociable.

  • GitHub:

- Héberge le code actuel

  • un presque monopole de facto

  • de très bonnes fonctionnalités sociales

  • Propriétaire gratuit pour l’open source

  • outil propriétaire avec des API limitées pour importer / exporter les tickets

  • Exploite TravisCI pour l’intégration continue, mais c’est pas le mieux (on a souvent des soucis)

  • Assez limité sur la gestion des tickets, paas de catégorie, gestion de projet kanban

  • pas mal d’outils tierces sur le “market place” type huboard par exemple

- Gitlab :

  • Un clone 100 % Open Source de GitHub, soit hébergé, soit hébergeable sur les QGIS ou OSGEO

  • Evolution très rapide, stable, réactif aux demandes

  • A notre goût chez Oslandia, infra d’intégration continue solide.

Et enfin en conduite de projet, c’est toujours une bonne idée de pas tout changer à la fois !

Voilà pour l’information nécessaire pour éclairer le débat :slight_smile:

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)

_______________________________________________ QGIS-fr-user mailing list QGIS-fr-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Le 19 janvier 2018 à 11:41, DelazJ <delazj@gmail.com> a écrit :

Bonjour,

Il y a en ce moment un sujet sur la liste développeurs de QGIS qui pourrait faire l’objet d’un vote dans les prochains jours donc, comme promis, je l’évoque ici afin d’avoir les avis du groupe sur le sujet: la migration du dépôt de signalement de bugs de QGIS.

Le lien vers la discussion en anglais est http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Last-call-for-switching-to-github-issue-tracker-td5349599.html

Une tentative de résumé : Il semble que le site https://issues.qgis.org n’est pas des plus pratiques/(plus adapté?) aux besoins de QGIS et qu’une meilleure intégration consisterait à migrer vers https://github.com/qgis/QGIS.

D’autres alternatives de dépôt plus ouvert ont aussi été évoquées dans la discussion.

En attendant de savoir clairement quelles vont être les options sur lesquelles il faudra se prononcer, il serait intéressant de partager ici (ou dans la discussion d’origine) votre expérience/impression de l’outil actuel de report de bugs (si vous en êtes utilisateur - régulier ou très occasionnel): prise en mains, navigation, recherche, ce que vous appréciez, ce qui manquerait…

Cordialement,
Harrissou


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Bonjour,

Juste pour signaler qu’en l’état actuel des échanges et sauf expression contraire entre temps, le non (au remplacement de Redmine par Github) sera le choix de la communauté FR, exprimée par la voix d’Alain et moi-même (vu de ma petite lorgnette de signaleur de bugs et de chercheur de bugs multicritères, je préfère la faculté qu’offre Redmine de pouvoir sauvegarder sa propre liste de signalements au lieu de se retaper la requête tout le temps sous GH; + qqs considérations d’ordre purement open source).

Régis, même si je connais ta position (via la liste dév et ton vote déjà effectué) et vu que tu ne l’as pas exprimée ici, par souci de transparence, je ne t’ai du coup pas compté.

Bon week-end à tous,

Harrissou

···

Le 30 janvier 2018 à 13:08, DelazJ <delazj@gmail.com> a écrit :

C’est noté, Alain. Merci.

Harrissou

Le 30 janvier 2018 à 11:08, FERRATON Alain (Chef de groupe) - SG/SPSSI/CPII/DOO/ET <Alain.Ferraton@developpement-durable.gouv.fr> a écrit :

Bonjour à tous,

Coté utilisateur le redmine bien que surement imparfait nous convient.
j’ai une position assez proche du QGIS Italy user group.

Cordialement,

FERRATON Alain
Ministère de la Transition écologique et solidaire (MTES)
SG/SPSSI/CPII/DOO
Chef du groupe Expertise Technique
02.40.12.84.08

Le 30/01/2018 à 10:49, “> DelazJ (par Internet, dépôt qgis-fr-user-bounces@lists.osgeo.org)” a écrit :

Bonjour à tous

Merci à Régis pour ce propos qui permet effectivement de replacer plus clairement les attendus des uns et des autres selon leur profil (et sensibilité) sur ce que serait une plateforme idéale.

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Le 24 janvier 2018 à 08:54, Jean-Marie Arsac <jmarsac@azimut.fr> a écrit :

Salut,

Je crois que Régis n’a rien oublié :slight_smile: J’adhère à son analyse

Pour l’anecdote, j’ajouterai juste que je suis toujours un peu surpris de constater l’importance d’usage, dans les projets Open Source, d’outils propriétaires comme github ou de matériels issus de constructeurs à la politique commerciale pas vraiment ouverte comme les MACs.

Certains parleront de principe de réalité; à titre perso, je ne pense pas que cela rende très lisible le discours sur l’Open Source, surtout lorsque des alternatives communautaires peuvent émerger.

Et une question : Quid de gogs/gitea ?

Aucune idée. Je t’avoue que les alternatives à GH n’ont pas tellement été évoquées.

Pour revenir au sujet principal, L’idée ici était donc de savoir, au regard de votre profil, si https://issues.qgis.org/projects/qgis répond bien à votre besoin (facile à prendre en mains ou pas, quelle(s) amélioration(s) possible(s)…) mais faute de retours…

Pour info, un vote vient d’être mis en place pour décider si on devait abandonner la plateforme actuelle pour migrer sur Github pour tout nouveau signalement de bugs ou nouvelle demande de fonctionnalités (https://www.loomio.org/d/cDwCmhsG/proposal-to-shift-bug-issue-tracking-work-to-github-issues-for-qgis-3x-). La période de vote prend fin lundi à l’aube donc le vote du groupe FR sera issu de ceux qui se seront exprimés d’ici samedi minuit.

Géomatiquement,

Harrissou

A bientôt.

jm

Le 19/01/2018 à 14:52, Régis Haubourg a écrit :

Bonjour à tous,

merci Harrissou de remonter le sujet et de consulter la communauté avant le vote.

Essayons de poser les enjeux et les fonctionnalités attendues d’un gestionnaire du tickets idéal pour le projet QGIS.

Pour les demandeurs:

  • Permettre de saisir simplement des tickets d’anomalie ou de demande d’évolution

  • Permettre de rechercher efficacement (vite et juste) des tickets similaires pour éviter le doublonnage de tickets. Une bonne indexation par les moteurs de recherche externe est un point critique.

  • Permettre d’inclure simplement des illustrations, images animées

  • Permettre de ‘pinguer’ facilement quelqu’un pour l’inviter à la discussion

  • Avoir un système d’authentification unifié avec l’OSGEO pour éviter la démultiplication des mots de passe, profils, identifants, etc…

  • Permettre de tagguer des caractéristiques (type de demande, catégorie, plateforme impactées, version cible etc…)

Pour les gestionnaires du tracker:

  • Permettre de gérer des catégories et d’assigner automatiquement un ou plusieurs responsables pour affiner le statut du ticket

  • sauvegarder des requêtes type

  • exporter / importer des tickets, les PJ, illustrations et tous les commentaires pour pouvoir changer de plateforme au besoin

  • Suivre l’avancement des tâches (tableau kanban par exemple)

  • Limiter les tâches de maintenance serveur (hébergement, maintenance, gestion d’urgence)

Pour les développeurs:

  • être efficacement lié au système d’hébergement du code source

  • être notifié / pouvoir notifier activement quelqu’un

  • garder le lien entre un numero de ticket, une pull request et le ticket.

  • automatiser un maximum la fermeture de ticket avec des mots clés type “Fix #1755

  • avoir un système fiable et robuste d’intégration continue couplé

Pour les financeurs:

  • garder une référence unique et stable dans le temps

  • assurer un espace unique de discussion entre utilisateurs, développeurs, et commanditaires

Pour la communauté OSGEO:

  • Choisir un outil non propriétaire et nous laissant maître de nos données

  • Eviter la dispersion des outils de l’infrastructure OSGEO

Sans oublier quelques facteurs externes, comme le bruit généré par la difficulté à obtenir un login OSGEO, en lien avec le système de “mantra” antispam que nous avons dû mettre en place pour éviter les attaques de spam. Le système est lourd humainement, pas simple à comprendre, et constitue un frein évitable, mais pour l’instant, aucune solution antispam automatique efficace n’a été trouvée.

N’hésitez pas à compléter si j’en oublie, mais il n’y a actuellement pas d’outil parfait pour toutes ces exigences.

En résumé très rapide, ce que je peux dire sur les outils en lice:

- Redmine:

  • l’outil actuel, très paramètrable, hébergé par QGIS, avec de nombreuses possibilité d’adaptation.

  • Conception ancienne, peu couplé aux outils de gestion de code (mais couplé quand même)

  • Recherche lourde, pas très efficace, indexation google perfectible

  • Open source et maitrise totale de nos données

  • Un peu de boulot de gestion des machines (on a eu quelques pannes par moment)

  • Outil découplé des infrastructures OSGEO, avec une situation inconfortable permettant à des utilisateurs de se logguer sans login osgeo, et donc sans faire comprendre que tous les outils FOSS4G sont un tout indissociable.

  • GitHub:

- Héberge le code actuel

  • un presque monopole de facto

  • de très bonnes fonctionnalités sociales

  • Propriétaire gratuit pour l’open source

  • outil propriétaire avec des API limitées pour importer / exporter les tickets

  • Exploite TravisCI pour l’intégration continue, mais c’est pas le mieux (on a souvent des soucis)

  • Assez limité sur la gestion des tickets, paas de catégorie, gestion de projet kanban

  • pas mal d’outils tierces sur le “market place” type huboard par exemple

- Gitlab :

  • Un clone 100 % Open Source de GitHub, soit hébergé, soit hébergeable sur les QGIS ou OSGEO

  • Evolution très rapide, stable, réactif aux demandes

  • A notre goût chez Oslandia, infra d’intégration continue solide.

Et enfin en conduite de projet, c’est toujours une bonne idée de pas tout changer à la fois !

Voilà pour l’information nécessaire pour éclairer le débat :slight_smile:

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)

_______________________________________________ QGIS-fr-user mailing list QGIS-fr-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Le 19 janvier 2018 à 11:41, DelazJ <delazj@gmail.com> a écrit :

Bonjour,

Il y a en ce moment un sujet sur la liste développeurs de QGIS qui pourrait faire l’objet d’un vote dans les prochains jours donc, comme promis, je l’évoque ici afin d’avoir les avis du groupe sur le sujet: la migration du dépôt de signalement de bugs de QGIS.

Le lien vers la discussion en anglais est http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Last-call-for-switching-to-github-issue-tracker-td5349599.html

Une tentative de résumé : Il semble que le site https://issues.qgis.org n’est pas des plus pratiques/(plus adapté?) aux besoins de QGIS et qu’une meilleure intégration consisterait à migrer vers https://github.com/qgis/QGIS.

D’autres alternatives de dépôt plus ouvert ont aussi été évoquées dans la discussion.

En attendant de savoir clairement quelles vont être les options sur lesquelles il faudra se prononcer, il serait intéressant de partager ici (ou dans la discussion d’origine) votre expérience/impression de l’outil actuel de report de bugs (si vous en êtes utilisateur - régulier ou très occasionnel): prise en mains, navigation, recherche, ce que vous appréciez, ce qui manquerait…

Cordialement,
Harrissou


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Bonsoir à tous,

super Harrissou, merci pour le retour !

En effet, sur mon vote individuel, j’ai porté une position qui résume un peu le point de vue coté équipe Oslandia.

En résumé,

  • on préfère éviter de tout casser en même temps dans une infrastructure, avec la sortie de QGIS3, je ne pense pas que nous ayons suffisamment de ressources pour cela.

  • autant le code peut sortir facilement de github, autant les tickets constitue un patrimoine de valeur et ne sont pas simple à extraire. C’est un outil propriétaire avec des API qui nous posent souci en import- export, mais aussi sur le plan éthique, même si GitHub a fait énormément pour le développement des projets Open Source;

  • On a des alternatives comme Gitlab que nous utilisons en production, très solides, et probablement plus solides que Travis pour la partie Intégration continue

Mais quand même pour insister sur le besoin initial, Redmine reste un outil assez lourd, pas efficient en recherche, et pas très “social” . Pinguer quelqu’un, insérer une image reste lourd et est un frein quand on essaie de maintenir les tickets à jour (et qu’il y a des centaines d’interactions par semaine).

Bon weekend à tous!

Régis

···

Le 2 février 2018 à 17:29, DelazJ <delazj@gmail.com> a écrit :

Bonjour,

Juste pour signaler qu’en l’état actuel des échanges et sauf expression contraire entre temps, le non (au remplacement de Redmine par Github) sera le choix de la communauté FR, exprimée par la voix d’Alain et moi-même (vu de ma petite lorgnette de signaleur de bugs et de chercheur de bugs multicritères, je préfère la faculté qu’offre Redmine de pouvoir sauvegarder sa propre liste de signalements au lieu de se retaper la requête tout le temps sous GH; + qqs considérations d’ordre purement open source).

Régis, même si je connais ta position (via la liste dév et ton vote déjà effectué) et vu que tu ne l’as pas exprimée ici, par souci de transparence, je ne t’ai du coup pas compté.

Bon week-end à tous,

Harrissou


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Le 30 janvier 2018 à 13:08, DelazJ <delazj@gmail.com> a écrit :

C’est noté, Alain. Merci.

Harrissou

Le 30 janvier 2018 à 11:08, FERRATON Alain (Chef de groupe) - SG/SPSSI/CPII/DOO/ET <Alain.Ferraton@developpement-durable.gouv.fr> a écrit :

Bonjour à tous,

Coté utilisateur le redmine bien que surement imparfait nous convient.
j’ai une position assez proche du QGIS Italy user group.

Cordialement,

FERRATON Alain
Ministère de la Transition écologique et solidaire (MTES)
SG/SPSSI/CPII/DOO
Chef du groupe Expertise Technique
02.40.12.84.08

Le 30/01/2018 à 10:49, “> DelazJ (par Internet, dépôt qgis-fr-user-bounces@lists.osgeo.org)” a écrit :

Bonjour à tous

Merci à Régis pour ce propos qui permet effectivement de replacer plus clairement les attendus des uns et des autres selon leur profil (et sensibilité) sur ce que serait une plateforme idéale.

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Le 24 janvier 2018 à 08:54, Jean-Marie Arsac <jmarsac@azimut.fr> a écrit :

Salut,

Je crois que Régis n’a rien oublié :slight_smile: J’adhère à son analyse

Pour l’anecdote, j’ajouterai juste que je suis toujours un peu surpris de constater l’importance d’usage, dans les projets Open Source, d’outils propriétaires comme github ou de matériels issus de constructeurs à la politique commerciale pas vraiment ouverte comme les MACs.

Certains parleront de principe de réalité; à titre perso, je ne pense pas que cela rende très lisible le discours sur l’Open Source, surtout lorsque des alternatives communautaires peuvent émerger.

Et une question : Quid de gogs/gitea ?

Aucune idée. Je t’avoue que les alternatives à GH n’ont pas tellement été évoquées.

Pour revenir au sujet principal, L’idée ici était donc de savoir, au regard de votre profil, si https://issues.qgis.org/projects/qgis répond bien à votre besoin (facile à prendre en mains ou pas, quelle(s) amélioration(s) possible(s)…) mais faute de retours…

Pour info, un vote vient d’être mis en place pour décider si on devait abandonner la plateforme actuelle pour migrer sur Github pour tout nouveau signalement de bugs ou nouvelle demande de fonctionnalités (https://www.loomio.org/d/cDwCmhsG/proposal-to-shift-bug-issue-tracking-work-to-github-issues-for-qgis-3x-). La période de vote prend fin lundi à l’aube donc le vote du groupe FR sera issu de ceux qui se seront exprimés d’ici samedi minuit.

Géomatiquement,

Harrissou

A bientôt.

jm

Le 19/01/2018 à 14:52, Régis Haubourg a écrit :

Bonjour à tous,

merci Harrissou de remonter le sujet et de consulter la communauté avant le vote.

Essayons de poser les enjeux et les fonctionnalités attendues d’un gestionnaire du tickets idéal pour le projet QGIS.

Pour les demandeurs:

  • Permettre de saisir simplement des tickets d’anomalie ou de demande d’évolution

  • Permettre de rechercher efficacement (vite et juste) des tickets similaires pour éviter le doublonnage de tickets. Une bonne indexation par les moteurs de recherche externe est un point critique.

  • Permettre d’inclure simplement des illustrations, images animées

  • Permettre de ‘pinguer’ facilement quelqu’un pour l’inviter à la discussion

  • Avoir un système d’authentification unifié avec l’OSGEO pour éviter la démultiplication des mots de passe, profils, identifants, etc…

  • Permettre de tagguer des caractéristiques (type de demande, catégorie, plateforme impactées, version cible etc…)

Pour les gestionnaires du tracker:

  • Permettre de gérer des catégories et d’assigner automatiquement un ou plusieurs responsables pour affiner le statut du ticket

  • sauvegarder des requêtes type

  • exporter / importer des tickets, les PJ, illustrations et tous les commentaires pour pouvoir changer de plateforme au besoin

  • Suivre l’avancement des tâches (tableau kanban par exemple)

  • Limiter les tâches de maintenance serveur (hébergement, maintenance, gestion d’urgence)

Pour les développeurs:

  • être efficacement lié au système d’hébergement du code source

  • être notifié / pouvoir notifier activement quelqu’un

  • garder le lien entre un numero de ticket, une pull request et le ticket.

  • automatiser un maximum la fermeture de ticket avec des mots clés type “Fix #1755

  • avoir un système fiable et robuste d’intégration continue couplé

Pour les financeurs:

  • garder une référence unique et stable dans le temps

  • assurer un espace unique de discussion entre utilisateurs, développeurs, et commanditaires

Pour la communauté OSGEO:

  • Choisir un outil non propriétaire et nous laissant maître de nos données

  • Eviter la dispersion des outils de l’infrastructure OSGEO

Sans oublier quelques facteurs externes, comme le bruit généré par la difficulté à obtenir un login OSGEO, en lien avec le système de “mantra” antispam que nous avons dû mettre en place pour éviter les attaques de spam. Le système est lourd humainement, pas simple à comprendre, et constitue un frein évitable, mais pour l’instant, aucune solution antispam automatique efficace n’a été trouvée.

N’hésitez pas à compléter si j’en oublie, mais il n’y a actuellement pas d’outil parfait pour toutes ces exigences.

En résumé très rapide, ce que je peux dire sur les outils en lice:

- Redmine:

  • l’outil actuel, très paramètrable, hébergé par QGIS, avec de nombreuses possibilité d’adaptation.

  • Conception ancienne, peu couplé aux outils de gestion de code (mais couplé quand même)

  • Recherche lourde, pas très efficace, indexation google perfectible

  • Open source et maitrise totale de nos données

  • Un peu de boulot de gestion des machines (on a eu quelques pannes par moment)

  • Outil découplé des infrastructures OSGEO, avec une situation inconfortable permettant à des utilisateurs de se logguer sans login osgeo, et donc sans faire comprendre que tous les outils FOSS4G sont un tout indissociable.

  • GitHub:

- Héberge le code actuel

  • un presque monopole de facto

  • de très bonnes fonctionnalités sociales

  • Propriétaire gratuit pour l’open source

  • outil propriétaire avec des API limitées pour importer / exporter les tickets

  • Exploite TravisCI pour l’intégration continue, mais c’est pas le mieux (on a souvent des soucis)

  • Assez limité sur la gestion des tickets, paas de catégorie, gestion de projet kanban

  • pas mal d’outils tierces sur le “market place” type huboard par exemple

- Gitlab :

  • Un clone 100 % Open Source de GitHub, soit hébergé, soit hébergeable sur les QGIS ou OSGEO

  • Evolution très rapide, stable, réactif aux demandes

  • A notre goût chez Oslandia, infra d’intégration continue solide.

Et enfin en conduite de projet, c’est toujours une bonne idée de pas tout changer à la fois !

Voilà pour l’information nécessaire pour éclairer le débat :slight_smile:

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)

_______________________________________________ QGIS-fr-user mailing list QGIS-fr-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Le 19 janvier 2018 à 11:41, DelazJ <delazj@gmail.com> a écrit :

Bonjour,

Il y a en ce moment un sujet sur la liste développeurs de QGIS qui pourrait faire l’objet d’un vote dans les prochains jours donc, comme promis, je l’évoque ici afin d’avoir les avis du groupe sur le sujet: la migration du dépôt de signalement de bugs de QGIS.

Le lien vers la discussion en anglais est http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Last-call-for-switching-to-github-issue-tracker-td5349599.html

Une tentative de résumé : Il semble que le site https://issues.qgis.org n’est pas des plus pratiques/(plus adapté?) aux besoins de QGIS et qu’une meilleure intégration consisterait à migrer vers https://github.com/qgis/QGIS.

D’autres alternatives de dépôt plus ouvert ont aussi été évoquées dans la discussion.

En attendant de savoir clairement quelles vont être les options sur lesquelles il faudra se prononcer, il serait intéressant de partager ici (ou dans la discussion d’origine) votre expérience/impression de l’outil actuel de report de bugs (si vous en êtes utilisateur - régulier ou très occasionnel): prise en mains, navigation, recherche, ce que vous appréciez, ce qui manquerait…

Cordialement,
Harrissou


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

Bonsoir,

Merci à vous. C’est aussi toute la difficulté de trouver un outil adapté à la fois aux développeurs qui suivent et mettent à jour les tickets et aux utilisateur qui “se contentent” de signaler les bugs :slight_smile:

Et si je vous ai bien lus, le passage à github pour la gestion des tickets ne satisferait pleinement ni les développeurs ni les utilisateurs.

Bon week end.

jm

···

Le 02/02/2018 à 18:02, Régis Haubourg a écrit :

Bonsoir à tous,

super Harrissou, merci pour le retour !

En effet, sur mon vote individuel, j’ai porté une position qui résume un peu le point de vue coté équipe Oslandia.

En résumé,

  • on préfère éviter de tout casser en même temps dans une infrastructure, avec la sortie de QGIS3, je ne pense pas que nous ayons suffisamment de ressources pour cela.

  • autant le code peut sortir facilement de github, autant les tickets constitue un patrimoine de valeur et ne sont pas simple à extraire. C’est un outil propriétaire avec des API qui nous posent souci en import- export, mais aussi sur le plan éthique, même si GitHub a fait énormément pour le développement des projets Open Source;

  • On a des alternatives comme Gitlab que nous utilisons en production, très solides, et probablement plus solides que Travis pour la partie Intégration continue

Mais quand même pour insister sur le besoin initial, Redmine reste un outil assez lourd, pas efficient en recherche, et pas très “social” . Pinguer quelqu’un, insérer une image reste lourd et est un frein quand on essaie de maintenir les tickets à jour (et qu’il y a des centaines d’interactions par semaine).

Bon weekend à tous!

Régis

Le 2 février 2018 à 17:29, DelazJ <delazj@gmail.com> a écrit :

Bonjour,

Juste pour signaler qu’en l’état actuel des échanges et sauf expression contraire entre temps, le non (au remplacement de Redmine par Github) sera le choix de la communauté FR, exprimée par la voix d’Alain et moi-même (vu de ma petite lorgnette de signaleur de bugs et de chercheur de bugs multicritères, je préfère la faculté qu’offre Redmine de pouvoir sauvegarder sa propre liste de signalements au lieu de se retaper la requête tout le temps sous GH; + qqs considérations d’ordre purement open source).

Régis, même si je connais ta position (via la liste dév et ton vote déjà effectué) et vu que tu ne l’as pas exprimée ici, par souci de transparence, je ne t’ai du coup pas compté.

Bon week-end à tous,

Harrissou

Le 30 janvier 2018 à 13:08, DelazJ <delazj@gmail.com> a écrit :

C’est noté, Alain. Merci.

Harrissou

Le 30 janvier 2018 à 11:08, FERRATON Alain (Chef de groupe) - SG/SPSSI/CPII/DOO/ET <Alain.Ferraton@developpement-durable.gouv.fr> a écrit :

Bonjour à tous,

Coté utilisateur le redmine bien que surement imparfait nous convient.
j’ai une position assez proche du QGIS Italy user group.

Cordialement,

FERRATON Alain
Ministère de la Transition écologique et solidaire (MTES)
SG/SPSSI/CPII/DOO
Chef du groupe Expertise Technique
02.40.12.84.08

Le 30/01/2018 à 10:49, “> DelazJ (par Internet, dépôt qgis-fr-user-bounces@lists.osgeo.org)” a écrit :

Bonjour à tous

Merci à Régis pour ce propos qui permet effectivement de replacer plus clairement les attendus des uns et des autres selon leur profil (et sensibilité) sur ce que serait une plateforme idéale.

Le 24 janvier 2018 à 08:54, Jean-Marie Arsac <jmarsac@azimut.fr> a écrit :

Salut,

Je crois que Régis n’a rien oublié :slight_smile: J’adhère à son analyse

Pour l’anecdote, j’ajouterai juste que je suis toujours un peu surpris de constater l’importance d’usage, dans les projets Open Source, d’outils propriétaires comme github ou de matériels issus de constructeurs à la politique commerciale pas vraiment ouverte comme les MACs.

Certains parleront de principe de réalité; à titre perso, je ne pense pas que cela rende très lisible le discours sur l’Open Source, surtout lorsque des alternatives communautaires peuvent émerger.

Et une question : Quid de gogs/gitea ?

Aucune idée. Je t’avoue que les alternatives à GH n’ont pas tellement été évoquées.

Pour revenir au sujet principal, L’idée ici était donc de savoir, au regard de votre profil, si https://issues.qgis.org/projects/qgis répond bien à votre besoin (facile à prendre en mains ou pas, quelle(s) amélioration(s) possible(s)…) mais faute de retours…

Pour info, un vote vient d’être mis en place pour décider si on devait abandonner la plateforme actuelle pour migrer sur Github pour tout nouveau signalement de bugs ou nouvelle demande de fonctionnalités (https://www.loomio.org/d/cDwCmhsG/proposal-to-shift-bug-issue-tracking-work-to-github-issues-for-qgis-3x-). La période de vote prend fin lundi à l’aube donc le vote du groupe FR sera issu de ceux qui se seront exprimés d’ici samedi minuit.

Géomatiquement,

Harrissou

A bientôt.

jm

Le 19/01/2018 à 14:52, Régis Haubourg a écrit :

Bonjour à tous,

merci Harrissou de remonter le sujet et de consulter la communauté avant le vote.

Essayons de poser les enjeux et les fonctionnalités attendues d’un gestionnaire du tickets idéal pour le projet QGIS.

Pour les demandeurs:

  • Permettre de saisir simplement des tickets d’anomalie ou de demande d’évolution

  • Permettre de rechercher efficacement (vite et juste) des tickets similaires pour éviter le doublonnage de tickets. Une bonne indexation par les moteurs de recherche externe est un point critique.

  • Permettre d’inclure simplement des illustrations, images animées

  • Permettre de ‘pinguer’ facilement quelqu’un pour l’inviter à la discussion

  • Avoir un système d’authentification unifié avec l’OSGEO pour éviter la démultiplication des mots de passe, profils, identifants, etc…

  • Permettre de tagguer des caractéristiques (type de demande, catégorie, plateforme impactées, version cible etc…)

Pour les gestionnaires du tracker:

  • Permettre de gérer des catégories et d’assigner automatiquement un ou plusieurs responsables pour affiner le statut du ticket

  • sauvegarder des requêtes type

  • exporter / importer des tickets, les PJ, illustrations et tous les commentaires pour pouvoir changer de plateforme au besoin

  • Suivre l’avancement des tâches (tableau kanban par exemple)

  • Limiter les tâches de maintenance serveur (hébergement, maintenance, gestion d’urgence)

Pour les développeurs:

  • être efficacement lié au système d’hébergement du code source

  • être notifié / pouvoir notifier activement quelqu’un

  • garder le lien entre un numero de ticket, une pull request et le ticket.

  • automatiser un maximum la fermeture de ticket avec des mots clés type “Fix #1755

  • avoir un système fiable et robuste d’intégration continue couplé

Pour les financeurs:

  • garder une référence unique et stable dans le temps

  • assurer un espace unique de discussion entre utilisateurs, développeurs, et commanditaires

Pour la communauté OSGEO:

  • Choisir un outil non propriétaire et nous laissant maître de nos données

  • Eviter la dispersion des outils de l’infrastructure OSGEO

Sans oublier quelques facteurs externes, comme le bruit généré par la difficulté à obtenir un login OSGEO, en lien avec le système de “mantra” antispam que nous avons dû mettre en place pour éviter les attaques de spam. Le système est lourd humainement, pas simple à comprendre, et constitue un frein évitable, mais pour l’instant, aucune solution antispam automatique efficace n’a été trouvée.

N’hésitez pas à compléter si j’en oublie, mais il n’y a actuellement pas d’outil parfait pour toutes ces exigences.

En résumé très rapide, ce que je peux dire sur les outils en lice:

- Redmine:

  • l’outil actuel, très paramètrable, hébergé par QGIS, avec de nombreuses possibilité d’adaptation.

  • Conception ancienne, peu couplé aux outils de gestion de code (mais couplé quand même)

  • Recherche lourde, pas très efficace, indexation google perfectible

  • Open source et maitrise totale de nos données

  • Un peu de boulot de gestion des machines (on a eu quelques pannes par moment)

  • Outil découplé des infrastructures OSGEO, avec une situation inconfortable permettant à des utilisateurs de se logguer sans login osgeo, et donc sans faire comprendre que tous les outils FOSS4G sont un tout indissociable.

  • GitHub:

- Héberge le code actuel

  • un presque monopole de facto

  • de très bonnes fonctionnalités sociales

  • Propriétaire gratuit pour l’open source

  • outil propriétaire avec des API limitées pour importer / exporter les tickets

  • Exploite TravisCI pour l’intégration continue, mais c’est pas le mieux (on a souvent des soucis)

  • Assez limité sur la gestion des tickets, paas de catégorie, gestion de projet kanban

  • pas mal d’outils tierces sur le “market place” type huboard par exemple

- Gitlab :

  • Un clone 100 % Open Source de GitHub, soit hébergé, soit hébergeable sur les QGIS ou OSGEO

  • Evolution très rapide, stable, réactif aux demandes

  • A notre goût chez Oslandia, infra d’intégration continue solide.

Et enfin en conduite de projet, c’est toujours une bonne idée de pas tout changer à la fois !

Voilà pour l’information nécessaire pour éclairer le débat :slight_smile:

Le 19 janvier 2018 à 11:41, DelazJ <delazj@gmail.com> a écrit :

Bonjour,

Il y a en ce moment un sujet sur la liste développeurs de QGIS qui pourrait faire l’objet d’un vote dans les prochains jours donc, comme promis, je l’évoque ici afin d’avoir les avis du groupe sur le sujet: la migration du dépôt de signalement de bugs de QGIS.

Le lien vers la discussion en anglais est http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Last-call-for-switching-to-github-issue-tracker-td5349599.html

Une tentative de résumé : Il semble que le site https://issues.qgis.org n’est pas des plus pratiques/(plus adapté?) aux besoins de QGIS et qu’une meilleure intégration consisterait à migrer vers https://github.com/qgis/QGIS.

D’autres alternatives de dépôt plus ouvert ont aussi été évoquées dans la discussion.

En attendant de savoir clairement quelles vont être les options sur lesquelles il faudra se prononcer, il serait intéressant de partager ici (ou dans la discussion d’origine) votre expérience/impression de l’outil actuel de report de bugs (si vous en êtes utilisateur - régulier ou très occasionnel): prise en mains, navigation, recherche, ce que vous appréciez, ce qui manquerait…

Cordialement,
Harrissou


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)

_______________________________________________ QGIS-fr-user mailing list QGIS-fr-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user


QGIS-fr-user mailing list
QGIS-fr-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-fr-user

_______________________________________________
QGIS-fr-user mailing list
[QGIS-fr-user@lists.osgeo.org](mailto:QGIS-fr-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/qgis-fr-user](https://lists.osgeo.org/mailman/listinfo/qgis-fr-user)

-- 
Jean-Marie Arsac
Azimut
[http://www.azimut.fr](http://www.azimut.fr)
Mob 06 11 05 88 23