Utilisons github de manière plus propre

Un meilleur moyen de gerer le developpement du site

a marqué ce sujet comme résolu.

Reprise du dernier message de la page précédente

Pour utiliser Youtrack au boulot, je pense qu'il répond un peu toutes les exigences. Il est tres complet, on peut configurer le workflow comme on le veut avec plus ou moins d'états, de sous sytèmes, de sous tickets, etc.

Son principal défaut est celui de tous les outils Jetbrains, il est tellement complet et plein d'options qu'on si perd dans la configuration tellement il y a de possibilités. Donc si on l'utilise, bonne chance à celui qui va l'administrer.

Cependant une fois réglé, il y a pas grand chose à en dire.

+0 -0

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 )

Édité par Eskimon

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+1 -0

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.

Kje

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.

Mon Github — Tuto Homebrew — Article Julia

+0 -0
Auteur du sujet

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.

+0 -0

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.

+0 -0

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)

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+0 -0
Auteur du sujet

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.

+0 -0

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

+0 -0
Auteur du sujet

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.

+0 -0

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.

+0 -0

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 ?

J’ai les goûts les plus simples du monde, je me contente du meilleur O. Wilde

+1 -0

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 :)

+1 -0

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.

J’ai les goûts les plus simples du monde, je me contente du meilleur O. Wilde

+2 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte