Utilisons github de manière plus propre

creuse creuse creuse Y a quelqu'un ???

Bon, j'avais eu vent en MP de taiga.io . Voyons ses avantages…

• Primo, integration avec github, donc on aura pas a ramener les issues nous mêmes ;
• Secundo, c'est open-source, pourquoi pas ;
• Tertio, c'est du python, c'est meme du Django. Et avec un peu de chance et si on heberge nous meme ca veut dire qu'on va pouvoir brancher notre base d'user dessus comme ca pas besoin de recreer un compte…
• Et il y a les trucs habituels (du design, du kanban etc etc)

Les moins

• Faudrait l'heberger nous meme si on veut brancher nos users dessus (mais ca peut degager le forum B&S + le login GH)
• C'est dans un statut beta (release pour le mois de juin) avec dev actif (dernier commit sur GH il y a 2 jours)

Bref, un outil de plus qu'on peut s'amuser a considérer !

(Des screenshots si vous voulez : https://plus.google.com/photos/+WilWade/albums/6065617502503747761 )

J'aime bien l'idée de l'outil qui peut réutiliser directement notre base d'utilisateurs

C'est une supposition hein, je sais pas si c'est possible sans essayer… Si qqun un peu a l'aise avec Django veut faire un POC ca serait super cool !

On en a déjà parlé jesaisplusoù, le soucis actuel est que, si j'ai bonne mémoire, c'est du python3. Donc non-branchable pour le moment.

C'etait la effectivement ! Me souvenais d'Arius qui m'en parlait en MP mais je me souvenais plus l'avoir vue en public !

Ce serait possible d'avoir un module Django qui tourne avec Python 2 et un autre avec Python 3 hein. Surtout que là ils n'ont besoin de partager que le fichier settings.py, et l'accès à la base de donnée. Après je peut comprendre que ce soit une galère sans nom coté infra.

Yop le truc de python3 n'est pas un vrai problème, ZdS tournera surement avec python3 dans 3 releases.

Donc si besoin d'intégration de taiga.io, quelqu'un peut déjà travailler dessus.

Comment tu va faire avant que notre base fonctionne sur python 3 ?

Quand je dis travailler dessus, je parle de tout ce qu'il y'a a faire en amont (s'installer le truc en local pour tester un peu, voir s'il y'a pas de problème bloquant par rapport a notre architecture spécifique - debian, MySQL, npm vxx, etc. - ).

En gros tout préparer pour qu'il ne reste plus que la fusion a faire le moment venu.

En fait apres réflexion je ne sais pas si une intégration forte est une bonne idée : ça imposerait tout les dev a le récupérer en dépendance, les forks a en avoir un, etc. En fait une installation séparé est probablement plus simple et mieux pour le projet. Ça facilitera aussi le suivi de l'upstream. En fait pour moi la seule chose a faire est qu'on puisse se loguer avec son compte zds. Mais du coup en soit c'est la meme contrainte que les autres amplis de ce genre. Je ne pense pas qu'une intégration forte soit désirable.

En fait une installation séparé est probablement plus simple et mieux pour le projet.

C'est ce à quoi je pensais depuis le début en fait, faire tourner le bidule dans son coin et juste faire en sorte que les nouveaux comptes soient régulièrement ajoutés sur le truc (via un script journalier ou bricole du genre)

Pour moi, l'intégration forte est a proscrire, ne serait-ce que parce qu'on peut avoir besoin d'installer les deux outils sur deux serveur séparés (à cause des perfs). La seule chose qui a un intérêt à être partagé c'est la base des utilisateurs.

On peut aussi voir comment utiliser l'API pour lier nos utilisateurs à n'importe quel autre outil.

Le truc est que si on fait une installation séparé, cet outil n'a pas d'autres avantage que n'importe quel autre. On peut alors rajouter dans la liste : bugzilla, , jira, etc. C'est toujours le même problème du coup, avoir la même base d'utilisateurs

Bah si, le fait que comme les deux sont Django grosso modo la migration des comptes c'est une requete SQL bien faite non ? (alors que les autres tu pourras potentiellement pas le faire car mot de passe pas gérer de la meme facon etou)

C'est peut être facilité mais ça reste la même problématique. En fonction du service ça peut rester simple de d'autres façon.

Quand on y réfléchi bien, n'importe quel outil qui donne accès à une API de création d'utilisateur reste éligible (surtout si l'outil en question permet de s'affranchir de l'hébergement). Car un bout de code qui dit en gros "dès qu'un membre active son compte, connecte toi à l'API de tel outil et crée un nouvel utilisateur" serait suffisant.

Ok Du coup 0-0 on repart au début du choix Mais je vois pas comment vous compter créer les comptes identiques via API étant donnée que les mots de passe seront chiffré (et avoir une session partagées entre les outils auraient été le must )

Au final c'est toujours la même chose, faut juste trouver un service avec les fonctions necessaire et un dev pour faire la synchro de compte (je dis bien synchro car si tu change ton mot de passe ici, il doit être propagé sur l'autre serveur). Le plus dur reste d'avoir cette synchro car elle dépend de la bonne volonté d'un dev.

J'ai pas trop suivi, mais est-ce qu'il ne suffit pas (avec tout ce qu'implique cette expression ^^) de configurer un provider Oauth sur ZDS (ça devrait être assez facile avec Django je pense) et ensuite de plugger n'importe quel gestionnaire de ticket qui gère l'authentification Oauth ?

Est-ce que vous avez vraiment besoin de la synchronisation des comptes ? Évidemment, c'est un point positif, mais est-ce que ça vaut réellement le temps de travail qu'un mainteneur passera dessus plutôt que sur autre chose, ou les fonctionnalités que vous pourriez perdre par rapport à un système qui ne la propose pas ? Mon avis (de non-contributeur au code, et je ne m'attends pas trop à ce que ça change dans le futur, ce qui a l'inconvénient mais aussi l'avantage de ne pas avoir le nez dans vos discussions) est que vous ne devriez pas choisir votre futur outil en prenant en compte ce critère. Une fois que vous aurez un système qui remplit vos autres besoins, de deux choses l'une : soit c'est facile de lier les comptes, et c'est une feature rigolote, soit ça demande du travail, et je pense que ça reste raisonnable de demander aux contributeurs de créer et gérer eux-mêmes un deuxième compte (de toute façon, ils doivent déjà le faire sur github).

Pour reformuler plus simplement : le fait de demander aux utilisateurs de créer un compte spécifique au BT ne vous posera probablement jamais de problème comme ceux qui sont à l'origine de cette discussion, donc inutile de chercher à en inventer

Je crois que l'objectif à terme est de supprimer le forum B&S. Si tu veux faire ça sans perdre la moitié des gens au moment de créer le ticket décrivant le bug, il faut que l'étape "je m'identifie" soit la plus simple possible.