[QGIS-fr-user] Avis sur la plateforme de report de bug de QGIS
Jean-Marie Arsac
jmarsac at azimut.fr
Mar 23 Jan 23:54:59 PST 2018
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.
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 :)
>
> 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
> 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/20180124/3814b955/attachment.html>
Plus d'informations sur la liste de diffusion QGIS-fr-user