Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to PyQt5 #117

Merged
merged 2 commits into from Jul 12, 2016

Conversation

@a-wai
Copy link
Contributor

commented Jun 30, 2016

Corrige #116

@314r

This comment has been minimized.

Copy link
Owner

commented Jun 30, 2016

Wow, super. Un utilisateur m'a averti du problème il y a 2 jours, ce qui m'a donné l'occasion de pester contre Debian. Merci pour le boulot ! Je devrais avoir un peu de temps pour tester ça dans les jours qui viennent.

@314r

This comment has been minimized.

Copy link
Owner

commented Jul 2, 2016

Pour info, tu as testé la migration sous quel OS ?

@a-wai

This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2016

De nada ! Et j'ai testé sous debian (stable et testing), je n'ai que ça sous la main.

@314r

This comment has been minimized.

Copy link
Owner

commented Jul 3, 2016

Ok. Ça passe bien sous fedora également.
Sous OSX, ça s'annonce plus compliqué.

@314r

This comment has been minimized.

Copy link
Owner

commented Jul 4, 2016

Je progresse : Qtwebkit est deprecated depuis qt 5.5.
Va falloir passer à Qt WebEngine.

@314r

This comment has been minimized.

Copy link
Owner

commented Jul 4, 2016

Ok. Alors voici la situation :

  • Debian ne fournit plus QtWebkit pour pyqt4. Donc il faut abandonner pyQt4 pour pyQt5.
    • chez Qt5, Qtwebkit est deprecated depuis qt 5.5. Donc il faut abandonner QtWebkit.
    • Le remplaçant est Qt WebEngine. La migration a l'ait toute simple comme ça mais de plus près, ça s'annonce ingérable. Jusqu'à maintenant le code en javascript et le reste de l'application se parlaient comme de vrais gentlemen grâce à la fonction addToJavaScriptWindowObject. Mais ça, c'était avant. Pour avoir l'équivalent, il faut maintenant passer par Qt WebChannel qui m'a l'air d'être une bonne grosse usine à gaz qui va obliger à réécrire pas mal de code.
    • A tout ça s'ajoute un dernier problème : Qt WebEngine n'est pas dispo sous toutes les distributions. Autrement dit, il faut lâcher QtWebKit qui n'est plus dispo sous toutes les plateformes, mais d'un autre côté QtWebEngine n'est pas encore arrivé partout.

Bref.

  • soit je me trompe et tout ça va se faire sans aucun problème.
  • soit c'est peut-être l'occasion de lâcher Qt pour aller vers du Web pur ou à base d'Electron.
@a-wai

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2016

Hmmm, c'est ce que je craignais en lisant ton commentaire précédent...

Peut-être dans un 1er temps garder pyqt4 pour la version "standard", et maintenir une branche pyqt5/webkit pour les debian et assimilées (en espérant qu'ils ne retirent pas le support QtWebKit de pyqt5, cette fois).

Ca permettrait au moins d'avoir un soft qui marche pour tout le monde, le temps que tu voies quelle est la meilleure option pour la suite ?

@314r

This comment has been minimized.

Copy link
Owner

commented Jul 7, 2016

Oui, c'est probablement la meilleure option. A mon avis :

-pyqt5 pour les versions linux, j'ai l'impression que toutes les distros ont conservé le support de qtwebkit.
-pyqt4 pour windows et osx, histoire de ne pas trop toucher à la chaine d'outils (les cx_freeze et compagnie) qui est un peu sensible.

L'idée serait de fiabiliser au maximum la prochaine version, afin de ne pas avoir à y revenir trop rapidement et me laisser le temps de travailler sur la suite.

@314r 314r merged commit 20e7e79 into 314r:master Jul 12, 2016

@RemiCardona

This comment has been minimized.

Copy link

commented Jul 13, 2016

Du vécu dans plusieurs projets avec qt+python. Sur demande d'un client, on a essayé de supporter pyqt4 et pyside dans le même projet, pour qu'il puisse choisir "celui qui marche le mieux selon l'OS" (plusieurs versions de Windows, 2 versions de Debian).

Et bien ça rend fou. Vraiment fou. Ça fait perdre un temps précieux, les couts de débuggage et de maintenance explosent et au final personne n'y gagne. Alors 2 versions majeurs de pyqt, je n'imagine même pas la souffrance que ça doit être.

joliebulle a déjà pas mal de code, et une réécriture from scratch serait une perte sèche (cf le fiasco de Netscape/Mozilla à la fin des années 90/début 2000 pour la réécriture du moteur de rendu https://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite#Rewriting_from_scratch)

Je suggère donc ceci:

  • le projet principal joliebulle qui utlise des versions bornées (de python, de pyqt5, de certaines libs, etc)
  • un (ou plusieurs?) projet(s) "joliebulledeps" qui fournit tout le nécessaire à faire tourner joliebulle en étant le plus indépendant de ce qui est installé sur le système de l'utilisateur, utilisé par ceux qui sont sous windows (qui ne fournit rien), osx (qui fournit peu de choses) ou des versions anciennes de linux.

Ça se fait pas trop mal (cout initial non nul, mais ça s’amortit très vite vu que les emm**** diminuent très vite) à coup de script shell ou python, et puis de générer un gros zip/tarball "avec tout dedans".

C'est ce qui est fait pour distribuer Salome et ça marche raisonnablement bien. Il y a très probablement d'autres projets libres qui font ça et qui pourraient servir de base. Je pense à QGIS qui est écrit en Qt/C++ mais qui fournit des plugins python (donc avec pyqt).

Bonne chance!

@314r

This comment has been minimized.

Copy link
Owner

commented Jul 13, 2016

Merci pour ces conseils, que je vais méditer.
Je suis pessimiste quant à la poursuite du projet avec pyqt. Concrètement, pyqt4 est condamné à court ou moyen terme (c'est déjà le cas sous Debian) et le coût du portage vers qt5 va être énorme. Ce qui nous sauve pour le moment c'est que les distributions linux continuent de fournir qtwebkit pour qt5, mais ça s'arrêtera tôt ou tard.
Mais d'un autre côté, maintenir deux branches va être ingérable, je suis bien d'accord. C'est envisageable pour la prochaine version, mais c'est tout.

@njouanin

This comment has been minimized.

Copy link
Contributor

commented Aug 18, 2016

Salut,
Je reprends le fil de la discussion. C'est clair qu'avec pyqt c'est le stress à chaque release pour savoir si on va réussir à produire les paquets. Actuellement mes maigres contributions à ce projet consistent à produire la version Mac de joliebulle. Pour cela, je garde précieusement sur mon Mac une installation de Python avec PyQT qui semble fonctionner. Jusqu'à quand ...?
Est-ce que la solution ne consiste "simplement" pas à migrer joliebulle sur une techno indépendante de Qt. Je crois que tu avais entamé le portage en JS ? Est-ce que la cible n'est pas d'avoir une appli qui fonctionne directement dans un navigateur ?

@314r

This comment has been minimized.

Copy link
Owner

commented Aug 18, 2016

Merci de relancer la discussion, ce qui me donne l'occasion de préciser un
peu les plans pour le futur.
Effectivement, je pense que je n'irai pas plus loin avec la combinaison
python + qt. Sous Gnu/Linux la gestion des dépendances a toujours été
compliquée, sous Windows le code nécessite des petits ajustements et
l'environnement de développement est fragile, sous OS X l'équilibre est
toujours précaire et les bugs sont difficiles à tracer. Je constate par
ailleurs que la communauté de développeurs pyqt se vide sérieusement au fil
du temps.
L'idée est donc de profiter des développements récents sur JolieBulle, et
de la part de plus en plus importante de javascript dans le projet, pour
aller vers encore plus de web.
L'objectif est d'aller le plus loin possible dans le développement d'une
application web type offline-first qui s'exécutera exclusivement côté
client, et de revenir sur le bureau avec une solution type Electron. On
peut ainsi ménager 2 possibilités pour l'avenir, d'une part une application
web avec stockage des données en localstorage ou via RemoteStorage / Hoodie
/ Kinto, et d'autre part un logiciel de bureau avec stockage local des
fichiers.
La seule certitude c'est que je ne veux pas de code qui s'exécute côté
serveur et pas de base de données centralisée.

Le chantier pour migrer le code s'annonce assez énorme, mais peut-être pas
tant que ça non plus.
Je suis actuellement dans une phase de test, j'essaye plusieurs frameworks
js. Vue est un bon candidat.
Mais la perspective de loin la plus enthousiasmante est du côté de Elm. Je
développe activement depuis quelques jours avec ce langage. Je crains
d'être à un moment très limité par mes compétences, mais pour le moment
c'est vraiment une super expérience.
Sur le principe rien ne presse, la base actuelle fonctionne bien, même si
on devra peut-être sortir encore une ou deux versions de stabilisation. La
fenêtre pour développer une alternative est donc assez large, et faire des
choix à court terme me semble être un mauvais plan.

Le 18 août 2016 1:48 PM, "Nicolas" notifications@github.com a écrit :

Salut,
Je reprends le fil de la discussion. C'est clair qu'avec pyqt c'est le
stress à chaque release pour savoir si on va réussir à produire les
paquets. Actuellement mes maigres contributions à ce projet consistent à
produire la version Mac de joliebulle. Pour cela, je garde précieusement
sur mon Mac une installation de Python avec PyQT qui semble fonctionner.
Jusqu'à quand ...?
Est-ce que la solution ne consiste "simplement" pas à migrer joliebulle
sur une techno indépendante de Qt. Je crois que tu avais entamé le portage
en JS ? Est-ce que la cible n'est pas d'avoir une appli qui fonctionne
directement dans un navigateur ?


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#117 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADvj5UJqyQc3tpH1Exd05rtwNpJjeaStks5qhEafgaJpZM4JBs11
.

@njouanin

This comment has been minimized.

Copy link
Contributor

commented Aug 18, 2016

Niveau architecture, le compromis c'est peut-être la proposition de Penn-Mean sur ce post : un serveur installable en local par l'utilisateur et une interface web. Tout tourne en local ou à distance selon les besoins de l'utilisateur.
Niveau language, je me suis lancé de mon coté (pour d'autres projets) sur Scala. Tu peux faire de la programmation fonctionnelle comme en Elm, mais je le trouve plus intuitif, notamment car il n'impose pas de paradigme et tu peux même l'utiliser pour de la POO. Du coup la montée en compétence me semble moins difficile quand on vient de la programmation impérative comme moi. Par ailleurs il s'appuie sur la JVM Java et donc tu peux te raccrocher à tout l'écosystème qui va avec. Enfin, il y a le project scala-js qui est un compilateur scala->javascript.

@njouanin

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2016

Après avoir fait le tour des technos que tu cites, je comprends mieux l'idée. Kinto/remotestorage/hoodie permettent tous les 3 d'avoir un stockage local (navigateur ou appli bureau) qui se synchronise au besoin sur un serveur.
Kinto a l'air plus mature et plus actif que remotestorage, notamment. Par contre j'aime bien le concept de remotestorage qui permet via Oauth2 de donner des accès à des applis tierces. Kinto a l'air moins souple la dessus.
As-tu jeté un oeil à React ?

@314r

This comment has been minimized.

Copy link
Owner

commented Aug 20, 2016

Oui React est incontournable en ce moment. C'est une solution très
inconfortable de mon point de vue : une API qui évolue vite, des bonnes
pratiques très mouvantes, et un tooling pléthorique. J'y reviendrai
peut-être mais pour le moment je vais continuer avec Elm.

Kinto semble effectivement plus mature, mais moins complet : pas de
gestion de l'authentification par exemple. Sur le papier, remotestorage
pourrait faire l'affaire.

En pratique, je pense qu'il est raisonnable d'abstraire tout ce qui est en
rapport avec le stockage des données, puis de prendre une décision en temps
voulu. Et encore une fois, la solution sera peut-être un logiciel de bureau
avec stockage basé sur le système de fichiers. A suivre.

Le 19 août 2016 4:24 PM, "Nicolas" notifications@github.com a écrit :

Après avoir fait le tour des technos que tu cites, je comprends mieux
l'idée. Kinto/remotestorage/hoodie permettent tous les 3 d'avoir un
stockage local (navigateur ou appli bureau) qui se synchronise au besoin
sur un serveur.
Kinto a l'air plus mature et plus actif que remotestorage, notamment. Par
contre j'aime bien le concept de remotestorage qui permet via Oauth2 de
donner des accès à des applis tierces. Kinto a l'air moins souple la
dessus.
As-tu jeté un oeil à React https://facebook.github.io/react/ ?


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#117 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADvj5SVMuKi88x2YAZTZkGLMRyr59Wsmks5qhbyhgaJpZM4JBs11
.

@314r

This comment has been minimized.

Copy link
Owner

commented Aug 22, 2017

Un an plus tard...
Le développement a été calme, calme, pour des raisons personnelles/professionnelles essentiellement. Je n'ai pas eu de temps/pas d'envie/pas de disponibilité pour faire avancer le projet.
Mais j'ai pris un peu de temps pour avancer (un peu) dans mes compétences et préciser mes envies pour la suite, si suite il y a. J'ai une première ébauche (disons pre-pre alpha...) qui tourne sous Electron, avec au final beaucoup de code recyclé.
Je devrais récupérer du temps libre à partir de la fin d'année. On verra ce que j'en fais.
La perspective d'être bénévole à vie du logiciel ne m'enthousiasme que modérément, tandis que la possibilité d'en tirer une quelconque rémunération me semble irréaliste. A suivre.

@njouanin

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2017

Cool d'avoir des nouvelles !
Je comprends le manque de motivation, même si tu avoir pas mal de retours positifs sur Joliebulle : il me semble pas mal utilisé (au moins par la communauté francophone).
De mon coté, je suis toujours sur l'idée de développer un logiciel qui serait "complémentaire" à joliebulle et qui prendrait en charge d'autres besoins, comme la gestion du brassin (genre feuille de route des opérations à réaliser le jour du brassage), le pilotage des équipements (au moins la récupération d'infos en provenance d'une carte électronique, genre brewpi), la gestion du stock, les achats/ventes, .... bref un truc infaisable tout seul sur le temps d'une vie (surtout sur du temps libre) ! Mais c'est pas grave, ça me donne un prétexte pour découvrir de nouvelles technos et m'occuper le cerveau à des choses intelligentes.
Je suis parti sur une architecture "classique" client/serveur via une API type REST. Côté serveur, je suis sur Scala (parce qu'il le vaut bien et quand je programme en Scala j'ai l'impression d'être intelligent). Coté client, je suis sur VueJS car ce me semble être actuellement ce qu'il y a de moins pire en Javascript. Ce type d'architecture permet d'envisager différent types d'installations : client/serveur installés ensemble sur un PC, partie serveur hébergée, appli mobile, ...
Voilà, à suivre également ici : https://gitlab.com/NicolasJouanin/beerfactory/

@j0ack

This comment has been minimized.

Copy link

commented Aug 23, 2017

Bonjour à tous !

Je n'avais pas vu ce fil de discussion qui parle du futur du projet, c'est un peu dommage de le retrouver dans des commentaires de MR, fermée qui plus est. Peut être faudrait-il migrer ça dans le wiki ?

Perso je viens juste d'embarquer sur le projet que je commence juste à utiliser. Je suis dév Python fullstack dans la vie et brasseur amateur à mes heures perdues, du coup c'est presque naturel que le projet m'ait séduit au premier coup d'oeil ^^.

Au niveau des considérations techniques, y a-t-il une raison particulière de passer sous une web app plutôt que continuer dans l'approche client lourd ? Si c'est uniquement pour se passer de PyQt il existe plusieurs alternatives pour faire des clients lourds multi plateforme avec Python (je me rends bien compte que le travail de migration serait énorme).

@encolpe

This comment has been minimized.

Copy link

commented Aug 23, 2017

Bonjour,
Je suis aussi un dev fullstack python et je peux aider à developper ou maintenir cette version. Le passage en web app ne changera pas le problème d'avoir à reprendre une partie du code à chaque fois que le framework évolue et la nécessité de supporter plusieurs version du framework.

@flagos

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2017

@314r

This comment has been minimized.

Copy link
Owner

commented Aug 28, 2017

Merci pour vos réactions sympathiques.
Honnêtement, la part technique du problème est très marginale. Joliebulle est déjà, en grande partie, une application web, la base de code à migrer reste modeste, et le chantier ouvre des perspectives finalement assez enthousiasmantes.
Il s’agit donc d’un problème d’arbitrage entre différents centres d’intérêts et différentes contraintes.
(je commence aussi avoir un petit problème avec la situation de bénévolat forcé qui prévaut dans le logiciel libre « indépendant », mais je ne m’étends pas sur ce sujet qui va nous emmener sur un terrain scabreux)

@njouanin

This comment has been minimized.

Copy link
Contributor

commented Oct 12, 2017

Salut @314r ,
Ça me "titille" de reprendre mes contributions à Joliebulle. Je me suis mis à Vue.js et je commence à bien avoir le truc en main. Du coup, je serais intéressé pour récupérer les travaux que tu as engagé pour la migration vers Electron. Peux-tu partager le code dans une branche ?
Pour la suite des discussions, je propose de rependre sur le forum brassageamateur ou ailleurs si vous le souhaitez.
A+

@314r

This comment has been minimized.

Copy link
Owner

commented Oct 13, 2017

Bonjour Nicolas,

Pour l'instant pas grand chose de partageable de mon côté, j'ai fait plusieurs essais épars et je ne les ai pas pas forcément conservés. Depuis le début de la semaine je me penche de nouveau sérieusement sur le sujet et je devrais arriver à une petite base de code qui servira de base pour la suite. L'objectif dans un premier temps c'est d'avoir un "machin" qui affiche la bibliothèque de recettes en mode lecture seule. Dès que j'y suis, je mets ça dans une branche.

Je garde un bon souvenir de mes expérimentation avec Vue, mais je me souviens aussi de quelques centaines de lignes de config webpack et j'entrevoyais quelques problèmes de maintenance. Je pense que je ne te suivrai pas sur cette voie, mais si tu veux développer un fork à JolieBulle tu as ma bénédiction sans aucune réserve.

@almet

This comment has been minimized.

Copy link

commented Jan 24, 2018

Salut à tou.te.s,

Ça fait plaisir d'avoir des discussions sur le futur de JolieBulle :-) Les techno avancées me paraissent chouettes (elm notamment).

J'arrive bien après la bataille, mais, quelques retours quand même:

Kinto semble effectivement plus mature, mais moins complet : pas de
gestion de l'authentification par exemple. Sur le papier, remotestorage
pourrait faire l'affaire.

Pour info je suis l'un des instigateurs de Kinto (je bossais il y a quelques années sur le projet encore, et mes anciens collègues continuent de s'amuser dessus), et il supporte bien sur l'authentification ! D'ailleurs, un client pour elm à été commencé, et fonctionne bien il me semble: https://github.com/Kinto/elm-kinto/

On a aussi bossé sur un petit logiciel de brassage à base d'Angular (enfin, surtout Fred). Y'a surement des trucs à reprendre la dedans -- ça s'appuye sur Kinto également (https://github.com/vieuxsinge/editor).

En tant que futurs brasseurs installés, on a moins de temps qu'avant pour développer des logiciels, mais on suit de près !

@314r

This comment has been minimized.

Copy link
Owner

commented Jan 26, 2018

@almet

This comment has been minimized.

Copy link

commented Jan 26, 2018

Ah, excellent ! Ça fait plaisir. J'en profite aussi pour dire que ça me fait bien plaisir: merci pour ton soft, et pour tes interventions sur le forum des brassams !

Pour Elm, dommage, mais je comprends bien tes réticences. Elm est peut-être encore un peu jeune pour sauter les deux pieds dedans (c'est souvent ce que je reproche aux nouveaux frameworks / languages -- il faut tout réadapter, comme par ex. avec React, qui paraissait une solution géniale pour tout le monde, mais qui en à fait déchanter plus d'un à la longue).

Mon avis sur ce genre de questionnements, c'est de prendre une technologie et de rester dessus, en faisant évoluer uniquement en cas de nécessité. Electron + Vue.js me semblent également un bon moyen d'avoir des contributions extérieures assez simples, ce qui me parait primordial pour un outil qui se veut libre, et qui serait peut-être plus difficile avec du Elm.

@njouanin (hello !) disait aussi avoir un peu de temps pour faire du Vue.js, et il n'est pas impossible que je trouve plus de temps pour de la contrib avec cette techno qu'avec du Elm (pour lequel j'ai encore à grimper la courbe d'apprentissage).

Comment est-ce que tu verrais ça pour faire un portage ? Comment est-ce qu'on pourrait t'aider ?

@314r

This comment has been minimized.

Copy link
Owner

commented Jan 28, 2018

Pour le portage, je pense développer et publier une petite application minimaliste qui permettrait

  • la lecture des recettes et tous les calculs qui vont avec
  • un mode brassage dans la lignée de joliebulle

et ensuite apporter des fonctionnalités supplémentaires à cette base (l'édition des recettes notamment).

Joliebulle et son successeur vont donc coexister pendant un moment.
Dans l'idéal, j'aimerais que la nouvelle application ne réinvente pas (complètement) la roue et puisse offrir une expérience différente, pour que de nouveaux utilisateurs puissent rapidement y trouver leur compte, même s'il manquera certaines fonctionnalités par ailleurs. A première vue ça pourrait passer par un design différent et surtout des options plus avancées en terme de configuration et de calculs.

Joliebulle garde une image de logiciel "simple et gratuit pour les débutants". En pratique le logiciel est aussi utilisé par des grosses associations et des micro-brasseries. J'ai de plus en plus de retours de ces utilisateurs, qui généralement ont les idées bien claires concernant leurs besoins et leurs attentes. C'est là que j'apprécierais vraiment une aide et des retours, pour continuer à développer un logiciel le plus adapté possible à leurs usages.

Sur le plan purement technique, le portage est brutal puisqu'il s'agit d'une réécriture pure et simple de la plus grosse partie du logiciel. Ceci dit, j'ai l'impression qu'il n'y a pas d'obstacle technique majeur.
Là, je fais un essai avec le template Vuepack, donc Vue + Electron + vue-router + vuex + vue-loader et webpack. Rien que de l'écrire ça me fait peur, mais il faut reconnaitre que ça marche bien, et que l'ensemble est bien foutu.

@almet

This comment has been minimized.

Copy link

commented Jan 28, 2018

Je me dis que ce serait bien cool de collaborer là-dessus.

L'éditeur de fred (linké plus haut) marche assez bien, et je suis en train de me motiver pour le faire évoluer en une sorte de github des recettes bière.

Je ne sais pas si la solution technique actuelle est géniale mais ça tourne et j'imagine que angular fait que c'est assez simple d'accès.

Ça me botterai bien d'en discuter un peu plus longuement pour voir si il ya moyen de réutiliser certains concepts existants pour la future version de joliebulle (ou ptet même réutiliser le code existant du logiciel de fred). Je ne sais pas encore quel temps je vais avoir pour bosser sur le code (peu j'imagine avec le démarrage de la brasserie) mais parfois j'aime bien geeker sur mon temps libre.

En tout cas, hésite pas à me notifier de premières versions si tu veux du feedback / de la revue de code, ce sera avec grand plaisir !

@njouanin

This comment has been minimized.

Copy link
Contributor

commented Jan 29, 2018

Salut,
De mon côté, je bidouille toujours avec Vue et toute sa bande (vuex, vue-router) et notamment vuetify qui peut être intéressant pour la partie composants graphiques.
Le problème c'est que je m'éparpille également à tester d'autres technos (par ex. elixir pour du backend) et donc je n'ai pas franchement avancé... ;) Mais ça me ferait également plaisir de travailler avec vous sur ce portage.

J'ai de plus en plus de retours de ces utilisateurs, qui généralement ont les idées bien claires concernant leurs besoins et leurs attentes. C'est là que j'apprécierais vraiment une aide et des retours, pour continuer à développer un logiciel le plus adapté possible à leurs usages.

As-tu formalisé le recueil de ses besoins. Ça serait intéressant pour avoir les orientations/priorités à donner.

Au fait, ça serait pas le moment de passer sur un autre mode de communication qu'un "pauvre" ticket github ? (slack, gitter, ou ce que vous voulez). Vous pouvez aussi me trouver sur mastodon : nico@mastodon.beerfactory.org
A+

@314r

This comment has been minimized.

Copy link
Owner

commented Jan 29, 2018

@almet

This comment has been minimized.

Copy link

commented Jan 29, 2018

@314r oui c'était fonctionnel que pour nous. Je suis en train de faire quelques modifs dessus, tu peux regarder la en attendant -- https://almet.github.io/

@314r

This comment has been minimized.

Copy link
Owner

commented Jan 30, 2018

@j0ack

This comment has been minimized.

Copy link

commented Jan 30, 2018

Pour discuter de tout ça je me suis permis de créer un channel IRC #joliebulle sur freenode si ça interesse du monde.

@314r 314r referenced this pull request Mar 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.