MichaelMure a écrit 27 commentaires

  • [^] # Re: Modération ?

    Posté par  (site Web personnel) . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 2.

    Est-ce qu'il est prévu de pouvoir modérer les tickets sur le repo central avant qu'ils soient ajoutés à la base qui sera clonée / syncée par les clones ? Comme dans Fossil en fait.

    C'est pas quelque chose que j'avais imaginé, mais je t'encourage à ouvrir un ticket pour démarrer une discussion et voir si ça trouve son public.

    Idem est-ce qu'il est possible d'avoir des notifications par email ?

    Difficile de faire ça avec juste une commande git. Mais le plan à long terme c'est de voir l'interface web évoluer en un portail public central qu'un projet pourrait héberger pour remplacer entièrement Github et autre. A ce moment là, ça devient possible d'envoyer des mails facilement.

    Et enfin est-ce que l'API est accessible en HTTP à partir d'un autre serveur / client ? Notamment je pense à la possibilité de créer un bug à partir d'un rapport d'erreur dans Sentry / etc.

    L'API GraphQL est uniquement accessible sur 127.0.0.1 actuellement, mais ça serait pas très compliqué d'ajouter une configuration pour ça. Où même d'ajouter une API REST minimaliste si GraphQL pose problème.

  • [^] # Re: Génération du token

    Posté par  (site Web personnel) . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 1.

    Puis-je récupérer les bugs anonymement ?

    Pour le pire ou le meilleur, j'ai choisi d'utiliser l'api V4 (graphql) de Github qui impose une authentification. Donc non actuellement.

    Puis-je fournir mon propre token plutôt que de taper mes identifiants ?

    Actuellement non, mais ça serait une bonne chose à avoir, par exemple avec un flag pour la commande git bug bridge configure. Mais ça demande d'avoir une bonne documentation pour expliquer comment générer le token et avec quelles options.

    Comment met-on à jour la liste des bugs (y a-t-il une commande similaire à "git fetch" ?) ?

    git bug pull

  • [^] # Re: Pourquoi que les bugs?

    Posté par  (site Web personnel) . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 2.

    Le projet est limité au bug simplement parce que son équipe de développement est composé d'une personne, qui a un boulot à plein temps maintenant. Mais ça serait très chouette d'appliquer la même technique à d'autres domaines.

  • [^] # Re: La taille ça compte...

    Posté par  (site Web personnel) . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 3.

    Du point de vue de l'utilisateur, il n'y a rien a nettoyer ou même à gérer. Les fichiers sont lié aux bugs, téléchargé par git en même temps, et seront nettoyé si le bug n'est plus présent localement.

    Alors oui, ça prend de l'espace disque, mais c'est tout à fait possible de ne récupérer qu'une sélection des bugs disponible sur le dépôt distant.

    Ajouter des fichiers binaires dans git à une mauvaise réputation, mais c'est surtout parce que git n'est pas capable de les fusionner en cas de conflit et parce qu'ils s'accumulent avec le temps. Mais pour git-but ce n'est respectivement pas et pas nécessairement un problème.

  • [^] # Re: Pourquoi une nouvelle branche?

    Posté par  (site Web personnel) . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 10.

    Plusieurs raisons:

    1. Faire ça dans une branche, ça implique d'avoir des données des bugs au même endroits que le code. C'est à mon avis une mauvaise idée: ça pollue, c'est facile d'éditer les infos des bugs sans faire exprès, et surtout ça veut dire que potentiellement, git prend la main et fait une fusion tout seul, donc probabilité non nulle de corrompre les données.
    2. Si tu travaille sur une branche, tu dois faire des fusions régulièrement pour avoir les dernières mise à jour des bugs. C'est déjà assez difficile d'avoir un historique propre juste pour le code, pas la peine d'en rajouter.
    3. Potentiellement, tu dois changer de branche pour accéder à une version plus récente ou parallèle des bugs, donc mettre tes changements en cours dans une stash, checkout, lecture, et retour dans l'autre sens. C'est ni efficace ni simple.
    4. Avoir les données des bugs à part ouvre beaucoup de possibilité, comme par exemple d'avoir des bugs indépendants les un des autres pour un checkout partiel, avoir une gestion des identités propres, etc, etc …
    5. C'est plus facile de communiquer avec d'autres tracker quand le modèle de donnée n'est pas trop éloigné.

    Mais tout ça, ça ne veut pas dire que les bugs ne peuvent pas être "conscient" de la notion de branche. C'est bien plus simple et souple de rajouter ce concept par la suite plutôt que de se lier les mains dans le dos tout de suite.

  • [^] # Re: Dommage que ce soit git only

    Posté par  (site Web personnel) . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 5. Dernière modification le 06/12/18 à 17:12.

    Dans l'absolu, ça serait pas forcement difficile de le porter sur Mercurial. Si c'est possible de faire correspondre les concepts et d'implémenter l'interface qui va bien (https://github.com/MichaelMure/git-bug/blob/master/repository/repo.go), ça devrait marcher.

    Mais je connais que vaguement Mercurial, aucune idée si c'est jouable …

  • [^] # Re: conflit avec git-extras

    Posté par  (site Web personnel) . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 2.

    Ça m’embête un peu de perdre la corrélation entre le nom du projet et la commande :-|

  • [^] # Re: conflit avec git-extras

    Posté par  (site Web personnel) . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 1.

    C'est vrai, il y a un conflit. Je réfléchis à sortir du système de commande git porcelain et à renommer le binaire en gb par exemple. Plus de conflit et des commandes plus courte.

  • [^] # Re: Permissions ? Merge-requests ? import/export ?

    Posté par  (site Web personnel) . En réponse au journal git-bug: un bug tracker distribué intégré dans git. Évalué à 3.

    En parlant de l’import/export, est-ce qu’un importeur/exporteur pour GitLab est prévu ?

    Un ingé de Gitlab semblait intéressé: https://gitlab.com/gitlab-org/gitlab-ce/issues/50435

    Mais essentiellement, il suffit que quelqu'un s'y colle. N'hésitez pas, promo sur les pull-requests !

    pourquoi avoir une commande push dédiée ?

    Un push normal avec les bonnes options marcherait, mais pas le pull parce que git-bug doit vérifier et fusionner les nouveaux changements à se sauce. Par soucis de cohérence, il y a les deux commandes spéciales dans git-bug. Au delà de ça, il y a aussi la volonté de découpler entièrement le workflow du code et des bugs.

  • [^] # Re: Excellente idée

    Posté par  (site Web personnel) . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 10.

    Le suivi des bugs de git-bug n'est pas fait avec git-bug actuellement, pour plusieurs raisons:

    • un bug tracker a besoin d'accepter des éditions d'utilisateurs qui n'ont pas les droits d'écriture sur le dépôt. A terme, l'idée est de faire tourner l'interface web comme un portail qui accepte des comptes utilisateurs externe et stocke les changements dans le dépôt git central d'un projet. Mais l'interface n'est pas encore prête pour ça.
    • l'idée de git-bug n'est pas forcement de remplacer les bug tracker existants, mais de rendre l'accès et l’édition offline possible, et de casser la dépendance à un service / une entreprise. Je n'ai personnellement pas de soucis particulier avec Github, mais si demain ça change, mes issues sont déjà accessible en local et je peux les migrer ailleurs.
  • [^] # Re: La taille ça compte...

    Posté par  (site Web personnel) . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 9. Dernière modification le 06/12/18 à 13:08.

    Quelle est l'espace utilisé par une centaine de bugs avec quelques images (disons une vingtaine) ?

    J'ai fais un test avec 10.000 bugs, 10 commentaires par bug (du vrai texte représentatif d'une discussion) et le résultat est de 21Mo après un git gc qui compresse les données. Bien sûr, si tu ajoute des images, ça fera gonfler la facture, de la même façon que dans un commit normal.

    Cela dit, chaque bug est indépendant, donc il est possible de récupérer qu'une copie partielle d'un dépôt, comme par exemple ignorer des bugs marqué comme "archivé", récupérer uniquement les bugs récents ou ceux où on participe à la discussion.

    Admettons que j'ai deux repositories dans lesquels je push. Des utilisateurs différents sur chaque remote.
    Les bugs vont-ils être mergés ou font-ils parti de "namespace" différents ?

    Si un bug est créer et poussé vers 2 dépôts différents, il a toujours le même identifiants et pourra être fusionné ultérieurement, même si il y a eu des changements des deux cotés. Bien sûr, même si il y aura toujours un état final "légal", l'historique sera probablement différent ce que tu attend. Dans un système distribué, tu ne peux pas te baser sur des dates/horaires pour déterminer l'ordre des évènements, donc il n'est pas possible d'entrelacer les opérations de manière fiable pendant la fusion. Dans la pratique, tu voudra probablement éviter ce scénario.

  • [^] # Re: Permissions ? Merge-requests ? import/export ?

    Posté par  (site Web personnel) . En réponse au journal git-bug: un bug tracker distribué intégré dans git. Évalué à 2.

    Je viens de réaliser que ta question sur les imports/exports c'est plutôt pour interroger git-bug depuis un autre programme. L'idée c'est que les outils en ligne de commande permette de s'interfacer pour faire des scripts ou autre. Par exemple, git bug comment <id> permet de lister les commentaires d'un bug. Actuellement, c'est uniquement une sortie en mode texte pour un humain, mais un flag pour sortir en JSON ou autre, c'est parfaitement faisable. Ou alors il y a l'API GraphQL :-)

    Au passage, le format de sérialisation dans les blobs git a très peu d'importance et a été choisis uniquement pour des raisons de performance et de taux de compression (cf https://github.com/MichaelMure/git-bug/issues/5#issuecomment-419228672). Le format d'import/export peut très bien être différent.

  • [^] # Re: A coupler avec une système de revue de code intégré à git

    Posté par  (site Web personnel) . En réponse au journal git-bug: un bug tracker distribué intégré dans git. Évalué à 2.

    Tout à fait, il y a même eu de l'inspiration. Cela dit, le modèle de données est assez différent, il se base sur les git notes, ce qui, dans mes souvenirs, est bien mon souple et potentiellement pose quelques soucis de résolution de conflit.

  • [^] # Re: Permissions ? Merge-requests ? import/export ?

    Posté par  (site Web personnel) . En réponse au journal git-bug: un bug tracker distribué intégré dans git. Évalué à 3. Dernière modification le 06/12/18 à 11:33.

    Par exemple si sur un projet je ne veux que les étiquettes "WIP", "v1.2.3" et "DEV" ?

    L'idée fondamentale de l'ergonomie de git-bug, c'est de fonctionner de base avec zéro configuration, et un ensemble de règle de base raisonnable qu'il sera possible d'ajuster pour des besoins particuliers. Pour les étiquettes, l'utilisateur est libre de saisir ce qu'il veut et git-bug propose dans son interface de sélectionner facilement une étiquettes existante. Dans le futur il sera possible d'ajouter des contraintes et de le limiter à un ensemble particulier.

    Mais tu va me dire, comment faire pour faire respecter des règles dans un système distribué ? Au final c'est assez simple. A la manière d'une blockchain, chaque client git-bug vérifie les nouveaux blocs de données et ignore simplement ceux qui ne respectent pas les règles. Tu peux librement faire ce que tu veux avec tes données locales, mais personne ne va les accepter.

    Et si je ne veux autoriser que toto et tata à modifier l'état du bug ? Est-ce qu'on peut modifier les commentaires des autres ?

    Actuellement, il n'y a pas de gestion forte des identités ni de gestion de droit. N'importe qui avec les droits d'écriture sur le dépôt peut créer, modifier ou éditer un bug et ses commentaires. Mais comme expliqué dans mon journal, c'est la suite du programme pour moi: avoir des profiles utilisateurs distribués avec les données des bugs, signer les opérations d'éditions et avoir un système de règles pour déterminer qui a le droit de faire quoi.

    Est-ce que ça aurait du sens d'étendre pour des merge requests ? Git permet bien entendu d'utiliser une branche pour ça, l'intérêt serait de permettre de commenter le code avant de pouvoir réellement merger la branche.

    Oui c'est tout à fait possible, mais largement en dehors de la portée du projet actuellement. Si il y a des volontaires, pas de soucis ;-)

    Ça se rapproche de ce que fait Fossil si je ne m'abuse

    Correct

    Comment ça marche pour créer un importeur/exporteur ? Ça a l'air d'être du JSON, y'a une API pour récupérer directement les opérations assemblées et le ticket final ? Je travaille sur un gestionnaire de tickets et de merge-requests décentralisé (basé sur XMPP), et ça m'intéresserait de pouvoir faire les tickets en local quand internet n'est pas dispo, et de pouvoir synchroniser après coup.

    Un importeur va simplement récupérer les informations depuis l'API du bug tracker distant et utiliser les fonctions de haut niveau de git-bug (créer un bug, ajouter un commentaire) pour répliquer les changements. Par exemple, l'importeur Github interroge l'API GraphQL de Github qui expose l'historique des éditions, compare avec les données existantes en local, insère les nouveaux changements tout en les taguant avec les identifiants unique Github pour pouvoir faire le lien pendant un futur import.

    Un exporteur va faire l'inverse, et répliquer les changements locaux non présent sur le tracker distant. Bien sûr, seul les changements dont tu es l'auteur pourront être répliqués, à moins de construire une vrai passerelle qui a des jetons d'API Github pour tout les auteurs, mais c'est pas au programme.

    Bonne continuation, c'est très prometteur.

    Merci :)

  • [^] # Re: GEGL

    Posté par  (site Web personnel) . En réponse à la dépêche Traitement d'image : Sortie de G'MIC 1.5.5.1. Évalué à 2.

    Ce que j'ai constaté, c'est que GIMP étant un logiciel très connu, il attire énormément de trolleurs, volontaire ou non. Il suffit de voir les multiples (au moins 10) threads de mails (specimen à 100+ ici) sur l'export de GIMP. Comme l'équipe est relativement limité, ça use parfois …

    Cela dit, si la tache de réaliser un meta-op GEGL pour interfacer G'MIC n'est pas insurmontable, je ne serai pas trop étonné de le voir codé pendant le LGM. Pippin est la personne a qui tu dois parler.

  • [^] # Re: Le truc interressant de ce journal

    Posté par  (site Web personnel) . En réponse au journal La transparence réseau arrive dans Wayland. Évalué à 0.

    Sauf que le nombre de balles et le ratio orange/blanc est fixé. Les tirages ne sont pas trop indépendants puisque obtenir BBBBBBBB réduirait les chances d'obtenir du blanc la prochaine fois. C'est pas encore suffisant pour de la cryptographie.

  • # Un retour sur le Vala ?

    Posté par  (site Web personnel) . En réponse au journal Tiny 'Nux Tarot, version 0.2. Évalué à 1.

    Bien ? Pas bien ? Des difficultés particulières ?

  • [^] # Re: mode 16 bit / 32 bit - high depth

    Posté par  (site Web personnel) . En réponse à la dépêche GIMP 2.8 est sorti : une fenêtre unique !. Évalué à 3.

  • [^] # Re: Merci

    Posté par  (site Web personnel) . En réponse à la dépêche GIMP 2.8 est sorti : une fenêtre unique !. Évalué à 8.

    De rien :-)

  • # C'est bon, mangez en !

    Posté par  (site Web personnel) . En réponse au journal Début du Google Summer of Code 2012. Évalué à 5.

    À tout point de vue (compétence en code, rencontre, employabilité, fun), c'est vraiment une bonne expérience !

    Si vous remplissez les conditions, lancez vous !

  • [^] # Re: GIMP

    Posté par  (site Web personnel) . En réponse à la dépêche Graphisme Libre et professionnalisme. Évalué à 4.

    Hola hola, on va rétablir quelques vérités ici.

    Mais il faut reconnaître que GIMP est assez difficile à prendre en main, et surtout n'évolue pas très vite. Il y avait eu une discussion à se sujet, car les développements se font dans la branche principale, et il suffit qu'il y est un seul blocage pour que GIMP ne soit pas release.

    Les dev en ont conscience, et ça devrait être corrigé pour les releases suivante. C'est en effet la raison qui fait que GIMP 2.8 n'est pas encore sortie (le single window mode qui n'était pas terminé).

    Et personnellement, je trouve sa dommage car il y a vraiment un grand potentiel. Blender me paraît être un très bon exemple : le dev est rapide, les nouveautés sont la, l'interface n'est pas mal foutu, la communauté est active .. Bref il y a un certain dynamisme que l'on ne retrouve pas (ou plus ?) avec GIMP. Même si certains plugins montrent à quel point le graphisme libre possède un immense potentiel.

    La Blender foundation a plusieurs dev' employés, ce qui accélère grandement les choses. A coté, GIMP fait pâle figure avec ses quelques développeurs bénévoles.

    Alors que c'est ce dernier qui a donné naissance à GTK, il ne sera porté vers la 3em version de GTK qu'avec GIMP 3, selon la roadmap. Autant dire que ce n'est pas pour tout de suite.

    Perdu, --> http://git.gnome.org/browse/gimp/log/?h=gtk3-port
    J'ai pas testé, mais à priori c'est fonctionnel. Ce n'est pas intégré à la version actuelle pour ne pas repousser encore la date de sortie d'une release.

    Il faudrait à mon avis des changements profonds du mode de développement pour (re)trouver un vrai dynamisme. Typiquement passer de svn à un gestionnaire de version décentralisé, dev les nouveautés dans des branches à part, une initiative pour accueillir les nouveaux contributeurs et un processus de développement mis un peu plus en avant.
    GIMP, GEGL et BABL sont hébergé sur GIT. Concernant les méthodes, j'ai répondu plus haut, il devrait y avoir du changement.

    Bon puis y'a aussi le point délicat de l'ergonomie, qui est à revoir. Bref, je pense sincèrement que GIMP et professionnalisme, c'est pas encore ça. Alors certes il y à d'autres logiciels de graphisme libre, mais techniquement je doute fortement qu'ils puissent séduire les professionnels.

    Les professionnels sont justement la cible de GIMP depuis quelques temps, pour ne pas faire le grand écart débutant/pro. Les retouches basiques sont laissé à des logiciels comme Krita.

  • [^] # Re: Lazarus

    Posté par  (site Web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 1.

    du Vala ( Sisi, malgré les " problèmes " de " brevets " )

    Ça ma intrigué, du coup j'ai cherché un peu. Un message sur la mailing list des dev' sur le sujet:
    https://mail.gnome.org/archives/vala-list/2010-November/msg00096.html

  • # Vala ?

    Posté par  (site Web personnel) . En réponse au journal Votre langage idéal ?. Évalué à 3.

    Voilà mon analyse:
    * C++
    Horriblement complexe, ce qui conduit chaque développeur à utiliser un sous-ensemble des fonctionnalités, de manière incompatible avec son voisin (Google par exemple, n'utilise pas les exceptions). Très difficile à maitriser.
    * Java
    Pas franchement mauvais, mais pas excellent non plus. La machine virtuelle qui mange la RAM, le garbage collector qui passe quand il veut...
    * C
    Très élégant en général, peu complexe, portable, puissant ... Beaucoup de bon point malgré son age. Coté moins bon, la difficulté de faire de l'objet, et trop bas niveau pour coder vite et bien.

    J'ai pendant longtemps eu l'impression qu'il manquait un langage au milieu de tout ça, un genre de chainon manquant. Je pense l'avoir trouvé avec Vala (ou au moins on s'en approche).
    * langage de haut niveau (très inspiré du C#)
    * se compile en C/GObject, donc forte portabilité et réutilisabilité du code (autant pour utiliser du code C en Vala que dans l'autre sens).
    * reference counting, donc une gestion mémoire automatique, en restant déterministe
    * utilise naturellement toute l'infrastructure GNOME (mais on est pas pour autant limité à ça)
    * plein de petit truc qui font que c'est un langage plutôt sympa à utiliser, et très efficace

    Vala Tutorial
    Vala for Java Programmers
    Vala for C# Programmers

  • # GIMP

    Posté par  (site Web personnel) . En réponse au journal Oh mon dieu, ils ont changé l'interface de Blender!. Évalué à 8.

    A noter que l'interface de GIMP en fenêtre unique est depuis quelques jours "feature complete" pour la sortie de GIMP 2.8, qui devrais arriver en fin d'année. Estimation de la date de sortie.

    Un autre troll de moins ?

  • [^] # Re: Groupes/effets de calques ?

    Posté par  (site Web personnel) . En réponse au journal 5 projets GSOC pour The Gimp. Évalué à 4.

    Ça dépend essentiellement de ce que tu veux faire, mais il y a un tronc commun. Ce ne sont pas des pré-requis, tu peux apprendre sur le tas comme je l'ai fait, mais leurs connaissances aident pas mal:
    * Les GObject (un bon moyen pour découvrir ça est de faire des essais avec un générateur de code comme celui présent dans Anjuta)
    * Les bases de GTK et de la Glib
    * Git
    * Les autotools
    * Un bon IDE, capable de faire des recherches efficaces dans le code et de l'autocomplétion (j'utilise Codelite, et parfois cscope en renfort)

    Après, suivant le domaine où tu veux bidouiller, il faudra pousser sur certains domaines:
    * Pour tout ce qui est traitement effectif sur l'image, les librairies BABL (abstraction des formats de pixels, ce qui va apporter le support CMYK par exemple), et GEGL (manipulation d'image non destructive grâce à un arbre d'opération sur les images, qui va apporter un gros tas de choses sympa)
    * Pour tout ce qui est UI, widget spécifique, support de tablette et autre, il faut pousser plus loin dans GTK