[QGIS-fr-user] Avis sur la plateforme de report de bug de QGIS
FERRATON Alain (Chef de groupe) - SG/SPSSI/CPII/DOO/ET
Alain.Ferraton at developpement-durable.gouv.fr
Mar 30 Jan 02:08:23 PST 2018
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 at 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 at azimut.fr
> <mailto:jmarsac at azimut.fr>> a écrit :
>
> Salut,
>
> Je crois que Régis n'a rien oublié :) 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
> <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-
> <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 :)
>>
>> Le 19 janvier 2018 à 11:41, DelazJ <delazj at gmail.com
>> <mailto:delazj at 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
>> <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 at lists.osgeo.org
>> <mailto:QGIS-fr-user at 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 at lists.osgeo.org <mailto:QGIS-fr-user at 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 at lists.osgeo.org
> <mailto:QGIS-fr-user at 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-fr-user
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.osgeo.org/pipermail/qgis-fr-user/attachments/20180130/a1321025/attachment-0001.html>
Plus d'informations sur la liste de diffusion QGIS-fr-user