J'ai l'impression que les techs seraient pour ouvrir les specs, mais c'est tout en haut de la hiérarchie que ça refuse. Il n'y a rien de particulier à comprendre je pense, c'est juste politique. Qui sait, peut être que ça changera un jour :)
Je sais qu'il existe des outils comme GPaste qui permettent de gérer un historique des éléments copiés dans le presse papier.
Je pense qu'avec une souris capable d'envoyer des appuies de touche de clavier (comme c'est le cas sur des modèles comme les Rival 3, 300, 310, 500, 600, 650, 700, 710, les Sensei RAW, TEN? et 310) ça doit être faisable de mapper un bouton sur un raccourci clavier permettant de coller un élément particulier de cet historique :)
N'étant pas un "gamer" je ne saisis pas pourquoi les souris standard ne conviennent pas. Qu'est-ce que ces souris ont de plus ?
J'apprécie le fait de pouvoir régler la sensibilité de ma souris, c'est l'un des principaux intérêts pour moi. Après je ne crache pas sur les LED de couleurs qui permettent une touche de personnalisation (même si c'est clairement inutile ;)).
Certains des modèles de chez SteelSeries permettent de mapper (matériellement) des boutons de la souris sur des touches de claviers. C'est une fonctionnalité qui m'intéresse de plus en plus : j'aimerais bien pouvoir configurer des raccourcis sur certains boutons pour accélérer mon travail quand je suis sur des logiciels comme Inkscape ou Gimp (pouvoir changer d'outil en utilisant les boutons de la souris).
Vu que SteelSeries est une société danoise, est-ce qu'il ne serait pas bon de les contacter pour leur proposer Rivalcfg ?
Enfin, étant un défenseur de l'interopérabilité, je pense qu'il serait bon d'exiger que les spécifications d'interface soient disponibles. À quand une loi européenne à ce sujet ?
C'est effectivement une société danoise à l'origine. Ils ont racheté Ideazone (une société américaine) il y a quelques années, et je pense que leur équipe technique est essentiellement aux US aujourd'hui.
Quoi qu'il en soit, j'ai posté lundi un message sur leur Reddit, et ils m'ont répondu (j'avais auparavant essayé de les contacter via Twitter sans grand succès). J'ai donc pu discuter avec eux, ils m'ont fournit quelques infos qui m'ont déjà permis d'ajouter une nouvelle souris (la Rival 300S, qui sera du coup dispo dans la v4.1 d'ici quelques temps).
Ils ne peuvent pas libérer les specs de leur matériel pour des raisons politiques interne (visiblement c'est un sujet qui revient sur le tapis régulièrement, et souvent à cause de Rivalcfg :D), mais par contre ils ne voient aucun problème à ce que je fasse le reverse engineering de leur matériel. Ils vont donc m'envoyer des souris pour que je puisse en améliorer le support (j'ai même déjà reçu le tracking du colis, ils ont fait super vite !).
J'avoue que de savoir que SteelSeries n'est pas hostile, ni indifférent au projet me redonne un bon coup de motivation. Et puis avoir un coup de main du fabricant va énormément aider ! :D
Il ne faut pas oublier également que Gitlab (tout comme Github d'ailleurs), propose des API, et je ne pense pas qu'elles cassent tous les 4 matins.
Il est donc également possible d'utiliser ces API pour importer des projets dans une autre forge (tout comme Gitlab le fait pour importer des projets depuis Github, Bitbucket ou Gitea).
Personnellement si je développais une forge, je m’appuierais sur les API pour les imports de projets plutôt que sur l'export ZIP… Ça sera mieux documenté et plus stable dans le temps. :)
Dans le zip exporté, les infos du projet, ses issues, MR, etc. sont exportées dans un JSON qui semble bien structuré. Le dépôt Git et le wiki (qui est aussi un dépôt Git), sont exportés sous forme de bundle Git. Donc il me semble assez facile d'exploiter ces données si on devait les traiter nous-même (import dans une forge exotique ou autre).
J'ai utilisé cette fonctionnalité cette semaine encore pour transférer un projet entre deux Gitlab, et ça s'est très bien passé : il a bien réattribué les contributions/issues/merge requests aux bons utilisateurs (qui étaient présents des deux côtés).
C'est valable pour toutes les forges ça, le fait de pas pouvoir migrer les tickets par exemple (c'est la 2nd plus grosse fonctionnalité d'une forge après tout).
Je tiens tout de même à préciser que Gitlab dispose d'une fonction d'export d'un projet (ça génère un zip avec tout dedans, y compris les issues, merge requests, wiki, board, tags, etc.).
Ce zip peut être réimporté en l'état dans n'importe quelle autre instance Gitlab.
De plus, Gitlab peut importer un dépôt depuis Github, Bitbucket, Gitea et quelques autres forges.
Pour ce qui est de Github en lui-même, il dispose d'APIs, et pas mal de projets existent pour exporter / réimporter les issues et d'autres éléments d'un projet.
(par exemple, devoir installer la pile ruby pour ça me gêne énormément).
Concernant Gitlab : de plus en plus de parties de Gitlab sont réécrites en Go, Ruby finira peut-être par disparaître.
Si tu cherches un truc moins usine à gaz que Gitlab, il y a Gitea. Il est écrit en Go est reste assez léger.
Tu as probablement raison, mais dans un premiers temps je préfère essayer de trouver un repreneur qui utilise ou a utilisé le logiciel… Je suis pas sur que ça intéresse quelqu'un de complètement extérieur au projet (surtout vu la qualité actuelle du code, ya du boulot pour nettoyer tout ça ^^')
Le README ne dit pas grand chose sur son fonctionnement. Les utilisateurs ne savent pas forcément qu'un fichier nommé COVER.(jpg|png) et toutes ses variantes (avec ., min/maj etc…, est considéré comme une pochette de disque/cassette/album.
… heu… oui, tu as raison ! 😅️
Ça a probablement dû être expliqué quelque part dans le thread sur les forums d'Ubuntu-fr, mais clairement ça devrait être dans le README ! C'est une information tellement évidente pour moi que je ne me suis même pas rendu compte qu'elle manquait. Merci !
Les fichiers au format mp3 et d'autres formats audio ou d'encapsulation peuvent contenir des tags id3 (ou autre, avec le plus rara APE_tag, ou encore plus rare MPEG-7), permettant d'embarquer une vignette (ou plus) dans le fichier. J'ai regardé le code python en diagonal, et n'ai pas l'impression que ce soit géré.
Tu as raison, ce n'est pas géré. Ça a déjà été suggéré plusieurs fois, mais je n'ai jamais implémenté cette fonctionnalité (et je n'aurais malheureusement pas le temps de m'en occuper pour le moment).
Ceci dit, il doit être possible de trouver (ou de faire) un script qui extrait les images depuis les fichiers audio et qui les écrit dans un fichier .cover.jpg pour que Cover Thumbnailer l'utilise.
Cela pourrait être utilisé pour représenter le dossier ou le fichier lui même si cela diffère par morceau par exemple.
Pour ce qui est du dossier, ça rentre dans le scope de Cover Thumbnailer, mais pour les fichiers eux-mêmes ce n'est plus le cas. Il existe de plus déjà des thumbnailers pour les fichiers audio. Sur mon Ubuntu 20.04 ils sont en tout cas présents et activés par défaut (Nautilus). 😃️
Tout comme la dépendance aux gros acteurs centralisés pose certains problèmes, l'autohébergement a lui aussi son lot d'inconvénients.
Pour moi, le principal souci de l'autohébergement, en dehors de son coût, des compétences nécessaires et de la charge de travail que ça représente, c'est la pérennité : si l'auteur d'un logiciel autohébergé perd toute motivation ou disparaît, tout son travail disparaît avec lui.
Il y a heureusement des solutions comme Internet Archive ou la possibilité de répliquer les dépôts de code sur des plateformes centralisées… Mais c'est pas toujours mis en œuvre, ou de manière incomplète.
Il y a quelque temps, j'ai passé une bonne heure à écumer le web à la recherche d'un petit programme qui avait complètement disparu de la circulation il y a des années (c'était vraiment un truc de niche). J'ai fini par trouver un zip avec le code source du logiciel au fin fond d'un site disparu qui avait heureusement été sauvegardé par quelqu'un sur la way back machine de l'Internet Archive. J'ai donc pu récupérer le code d'une version du logiciel, mais pas son historique (si toutefois il avait été développé en utilisant un VCS).
Je ne dis pas qu'il ne faut pas s'autohéberger hein, juste que chaque solution a ses inconvénients, et que chacun doit prendre ses décisions en fonction de ses priorités et/ou capacités.
J'avoue que je ne suis pas fan de leur nouvelle ergonomie #CétaitMieuxAvant… Mais bon c'est pas grave, je télécharge ce qui m'intéresse et ça me donne une excuse pour laisser tomber Spotify de temps en temps et ressortir mon bon vieux MPD. :D
il faut faire 20 aller-retours pour qu'il soit accepté, pour des questions de code-style (jamais documenté), qui auraient été plus rapidement patchées via un simple de l'auteur.
Perso j'ai arrêté de faire des retours sur le coding style sur mes projets (à moins que ça soit vraiment dégueulasse) :
Soit j'ai configuré un linter (ce qui donne des règles claires sur ce qui est attendu), et qui tourne dans la CI (donc le dev est prévenu tout de suite des trucs qui ne vont pas quand il fait sa pull request).
Soit j'en ai pas configuré et je n'ai donc pas le droit de me plaindre.
Je sais que je diverge du sujet initial, mais, la dépendance aux interfaces web je la vit assez mal perso, et toi?
Je comprends ton point de vue, ça casse un peu le côté décentralisé de Git.
Mais personnellement je bosse toute la journée (et une partie de la nuit) sur des tas de projets différents avec énormément de personnes différentes, et clairement, le workflow proposé par Github et Gitlab me simplifie énormément la vie !
Tu peux très rapidement jeter un coup d'œil à une PR et voir si ça semble OK ou si c'est pas la peine de t'y attarder maintenant,
L'intégration avec de la CI permet de valider pas mal de choses automatiquement sans aucune action de ma part (puis quand c'est un linter qui dit que le code est moche, c'est plus difficile de le prendre mal que lorsque c'est un humain qui te le dit, puis c'est indiscutable )
Et j'aime beaucoup le fait de pouvoir directement annoter tes remarques à l'endroit concerné, ouvrir une discussion sur chacune d'entre elles, etc.
J'utilise Github et Gitlab tous les jours, et clairement pour moi il s'agit de formidables outils de collaboration qui me font gagner énormément de temps.
En dehors de Jamendo et Dogmazic, je vois pas trop. Certains des artistes sont sur Youtube ou Spotify, mais du coup autant télécharger les morceaux sur Jamendo… '
Tu lui reproche quoi à Jamendo pour vouloir le remplacer ? :)
Bonjour, et tout d'abord merci et bravo pour ce travail, et félicitation pour le choix de faire évoluer ce logiciel, là où un abandon en rase campagne aurait été si facile !
En fait, pour être totalement honnête ma première décision avait été d'abandonner le logiciel (j'en parle rapidement sur l'article que j'ai publié sur mon blog)… Je ne pensais pas qu'il restait plus d'un ou deux utilisateurs, donc je trouvais que ça valait pas le coup de s'embêter à réparer… Mais devant le nombre de messages que j'ai reçu, j'ai finalement changé d'avis (comme quoi, quand vous utilisez un logiciel, faites-le savoir a son créateur, ça motive !).
pourquoi avoir choisi Github et pas un autre hébergement similaire (Gitlab par exemple, ou d'autre dépôts comme Framagit) ?
Réponse courte : par facilité.
Je comprends votre réticence vis-à-vis de l'utilisation de services centralisés, et à une époque j'aurais refusé d'aller sur Github également… Mais du fait de son côté centralisé, beaucoup de devs ont un compte sur Github, ce qui facilite les contributions (en termes de quantité). La friction est moins grande.
Il est plus facile de proposer un correctif ou d'ouvrir un ticket sur un site où on a déjà un compte que de devoir s'inscrire sur un nouveau site, puis de contribuer. Personnellement ça m'est déjà arrivé de renoncer à rapport un bug ou de proposer un correctif, par ce que j'étais en train de faire autre chose en même temps et que j'avais la flemme de créer un compte sur un n-ième site (oui je sais, c'est pas bien).
Ceci dit, le dépôt de Cover Thumbnailer sur Launchpad (qui était le lieu où était développé ce logiciel avant que je migre tous mes dépôts sur Github) est toujours automatiquement synchronisé avec le dépôt Github. Donc on a quand même des backups. :)
Mais un "nouveau" (si on peut dire :-)) projet peut, devrait oserais-je dire, opter pour une alternative moins centralisée, monopolistique, aux mains du grand méchant crosoft.
En fait j'ai migré le dépôt de Cover Thumbnailer sur Github en Juin 2017, c'est pas tout à fait nouveau donc. :)
[^] # Re: Des questions...
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Rivalcfg v4.0, un outil de configuration pour les souris SteelSeries. Évalué à 3.
Ahah, merci ! :D
[^] # Re: Des questions...
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Rivalcfg v4.0, un outil de configuration pour les souris SteelSeries. Évalué à 10.
J'ai l'impression que les techs seraient pour ouvrir les specs, mais c'est tout en haut de la hiérarchie que ça refuse. Il n'y a rien de particulier à comprendre je pense, c'est juste politique. Qui sait, peut être que ça changera un jour :)
[^] # Re: Souris multi-bouton et presse papier
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Rivalcfg v4.0, un outil de configuration pour les souris SteelSeries. Évalué à 4.
Je sais qu'il existe des outils comme GPaste qui permettent de gérer un historique des éléments copiés dans le presse papier.
Je pense qu'avec une souris capable d'envoyer des appuies de touche de clavier (comme c'est le cas sur des modèles comme les Rival 3, 300, 310, 500, 600, 650, 700, 710, les Sensei RAW, TEN? et 310) ça doit être faisable de mapper un bouton sur un raccourci clavier permettant de coller un élément particulier de cet historique :)
[^] # Re: Des questions...
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Rivalcfg v4.0, un outil de configuration pour les souris SteelSeries. Évalué à 4.
La dépêche était déjà en modération quand j'ai pu discuter avec eux, c'est pour ça que je n'en parle pas :)
[^] # Re: Des questions...
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Rivalcfg v4.0, un outil de configuration pour les souris SteelSeries. Évalué à 10.
J'apprécie le fait de pouvoir régler la sensibilité de ma souris, c'est l'un des principaux intérêts pour moi. Après je ne crache pas sur les LED de couleurs qui permettent une touche de personnalisation (même si c'est clairement inutile ;)).
Certains des modèles de chez SteelSeries permettent de mapper (matériellement) des boutons de la souris sur des touches de claviers. C'est une fonctionnalité qui m'intéresse de plus en plus : j'aimerais bien pouvoir configurer des raccourcis sur certains boutons pour accélérer mon travail quand je suis sur des logiciels comme Inkscape ou Gimp (pouvoir changer d'outil en utilisant les boutons de la souris).
C'est effectivement une société danoise à l'origine. Ils ont racheté Ideazone (une société américaine) il y a quelques années, et je pense que leur équipe technique est essentiellement aux US aujourd'hui.
Quoi qu'il en soit, j'ai posté lundi un message sur leur Reddit, et ils m'ont répondu (j'avais auparavant essayé de les contacter via Twitter sans grand succès). J'ai donc pu discuter avec eux, ils m'ont fournit quelques infos qui m'ont déjà permis d'ajouter une nouvelle souris (la Rival 300S, qui sera du coup dispo dans la v4.1 d'ici quelques temps).
Ils ne peuvent pas libérer les specs de leur matériel pour des raisons politiques interne (visiblement c'est un sujet qui revient sur le tapis régulièrement, et souvent à cause de Rivalcfg :D), mais par contre ils ne voient aucun problème à ce que je fasse le reverse engineering de leur matériel. Ils vont donc m'envoyer des souris pour que je puisse en améliorer le support (j'ai même déjà reçu le tracking du colis, ils ont fait super vite !).
J'avoue que de savoir que SteelSeries n'est pas hostile, ni indifférent au projet me redonne un bon coup de motivation. Et puis avoir un coup de main du fabricant va énormément aider ! :D
[^] # Re: Merci !
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Rivalcfg v4.0, un outil de configuration pour les souris SteelSeries. Évalué à 5.
Je suis content que Rivalcfg te soit utile ! Ça fait plaisir d'avoir d'autres retours que des rapports de bug des fois :D
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 2.
Il ne faut pas oublier également que Gitlab (tout comme Github d'ailleurs), propose des API, et je ne pense pas qu'elles cassent tous les 4 matins.
Il est donc également possible d'utiliser ces API pour importer des projets dans une autre forge (tout comme Gitlab le fait pour importer des projets depuis Github, Bitbucket ou Gitea).
Personnellement si je développais une forge, je m’appuierais sur les API pour les imports de projets plutôt que sur l'export ZIP… Ça sera mieux documenté et plus stable dans le temps. :)
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 2.
Dans le zip exporté, les infos du projet, ses issues, MR, etc. sont exportées dans un JSON qui semble bien structuré. Le dépôt Git et le wiki (qui est aussi un dépôt Git), sont exportés sous forme de bundle Git. Donc il me semble assez facile d'exploiter ces données si on devait les traiter nous-même (import dans une forge exotique ou autre).
La compatibilité des exports entre les versions de Gitlab est également bien documentée.
J'ai utilisé cette fonctionnalité cette semaine encore pour transférer un projet entre deux Gitlab, et ça s'est très bien passé : il a bien réattribué les contributions/issues/merge requests aux bons utilisateurs (qui étaient présents des deux côtés).
[^] # Re: Documentation sur le fichier utilisé et gestion des tags id3 et assimilés
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 4.
J'ai mi à jour le README avec plus d'informations sur le fonctionnement du logiciel. Merci encore de m'avoir fait remarquer à quel point ça manquait.
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 2.
Je tiens tout de même à préciser que Gitlab dispose d'une fonction d'export d'un projet (ça génère un zip avec tout dedans, y compris les issues, merge requests, wiki, board, tags, etc.).
Ce zip peut être réimporté en l'état dans n'importe quelle autre instance Gitlab.
De plus, Gitlab peut importer un dépôt depuis Github, Bitbucket, Gitea et quelques autres forges.
Pour ce qui est de Github en lui-même, il dispose d'APIs, et pas mal de projets existent pour exporter / réimporter les issues et d'autres éléments d'un projet.
[^] # Re: parles en sur reddit
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 2. Dernière modification le 16 juillet 2020 à 13:09.
Tu as probablement raison, mais dans un premiers temps je préfère essayer de trouver un repreneur qui utilise ou a utilisé le logiciel… Je suis pas sur que ça intéresse quelqu'un de complètement extérieur au projet (surtout vu la qualité actuelle du code, ya du boulot pour nettoyer tout ça
^^')[^] # Re: Documentation sur le fichier utilisé et gestion des tags id3 et assimilés
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 4.
… heu… oui, tu as raison ! 😅️
Ça a probablement dû être expliqué quelque part dans le thread sur les forums d'Ubuntu-fr, mais clairement ça devrait être dans le README ! C'est une information tellement évidente pour moi que je ne me suis même pas rendu compte qu'elle manquait. Merci !
Tu as raison, ce n'est pas géré. Ça a déjà été suggéré plusieurs fois, mais je n'ai jamais implémenté cette fonctionnalité (et je n'aurais malheureusement pas le temps de m'en occuper pour le moment).
Ceci dit, il doit être possible de trouver (ou de faire) un script qui extrait les images depuis les fichiers audio et qui les écrit dans un fichier
.cover.jpgpour que Cover Thumbnailer l'utilise.Pour ce qui est du dossier, ça rentre dans le scope de Cover Thumbnailer, mais pour les fichiers eux-mêmes ce n'est plus le cas. Il existe de plus déjà des thumbnailers pour les fichiers audio. Sur mon Ubuntu 20.04 ils sont en tout cas présents et activés par défaut (Nautilus). 😃️
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 2.
Tout comme la dépendance aux gros acteurs centralisés pose certains problèmes, l'autohébergement a lui aussi son lot d'inconvénients.
Pour moi, le principal souci de l'autohébergement, en dehors de son coût, des compétences nécessaires et de la charge de travail que ça représente, c'est la pérennité : si l'auteur d'un logiciel autohébergé perd toute motivation ou disparaît, tout son travail disparaît avec lui.
Il y a heureusement des solutions comme Internet Archive ou la possibilité de répliquer les dépôts de code sur des plateformes centralisées… Mais c'est pas toujours mis en œuvre, ou de manière incomplète.
Il y a quelque temps, j'ai passé une bonne heure à écumer le web à la recherche d'un petit programme qui avait complètement disparu de la circulation il y a des années (c'était vraiment un truc de niche). J'ai fini par trouver un zip avec le code source du logiciel au fin fond d'un site disparu qui avait heureusement été sauvegardé par quelqu'un sur la way back machine de l'Internet Archive. J'ai donc pu récupérer le code d'une version du logiciel, mais pas son historique (si toutefois il avait été développé en utilisant un VCS).
Je ne dis pas qu'il ne faut pas s'autohéberger hein, juste que chaque solution a ses inconvénients, et que chacun doit prendre ses décisions en fonction de ses priorités et/ou capacités.
[^] # Re: Diablo Swing Orchestra
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 3.
J'avoue que je ne suis pas fan de leur nouvelle ergonomie #CétaitMieuxAvant… Mais bon c'est pas grave, je télécharge ce qui m'intéresse et ça me donne une excuse pour laisser tomber Spotify de temps en temps et ressortir mon bon vieux MPD. :D
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 2.
Perso j'ai arrêté de faire des retours sur le coding style sur mes projets (à moins que ça soit vraiment dégueulasse) :
Soit j'ai configuré un linter (ce qui donne des règles claires sur ce qui est attendu), et qui tourne dans la CI (donc le dev est prévenu tout de suite des trucs qui ne vont pas quand il fait sa pull request).
Soit j'en ai pas configuré et je n'ai donc pas le droit de me plaindre.
Je comprends ton point de vue, ça casse un peu le côté décentralisé de Git.
Mais personnellement je bosse toute la journée (et une partie de la nuit) sur des tas de projets différents avec énormément de personnes différentes, et clairement, le workflow proposé par Github et Gitlab me simplifie énormément la vie !
J'utilise Github et Gitlab tous les jours, et clairement pour moi il s'agit de formidables outils de collaboration qui me font gagner énormément de temps.
[^] # Re: Diablo Swing Orchestra
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 1.
En dehors de Jamendo et Dogmazic, je vois pas trop. Certains des artistes sont sur Youtube ou Spotify, mais du coup autant télécharger les morceaux sur Jamendo… '
Tu lui reproche quoi à Jamendo pour vouloir le remplacer ? :)
[^] # Re: Diablo Swing Orchestra
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 4.
Pareil, j'avais découvert ça il y a longtemps sur Jamendo ! J'adore ce groupe ! <3
[^] # Re: (HS) Github
Posté par FLOZz (site web personnel) . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 7.
En fait, pour être totalement honnête ma première décision avait été d'abandonner le logiciel (j'en parle rapidement sur l'article que j'ai publié sur mon blog)… Je ne pensais pas qu'il restait plus d'un ou deux utilisateurs, donc je trouvais que ça valait pas le coup de s'embêter à réparer… Mais devant le nombre de messages que j'ai reçu, j'ai finalement changé d'avis (comme quoi, quand vous utilisez un logiciel, faites-le savoir a son créateur, ça motive !).
Réponse courte : par facilité.
Je comprends votre réticence vis-à-vis de l'utilisation de services centralisés, et à une époque j'aurais refusé d'aller sur Github également… Mais du fait de son côté centralisé, beaucoup de devs ont un compte sur Github, ce qui facilite les contributions (en termes de quantité). La friction est moins grande.
Il est plus facile de proposer un correctif ou d'ouvrir un ticket sur un site où on a déjà un compte que de devoir s'inscrire sur un nouveau site, puis de contribuer. Personnellement ça m'est déjà arrivé de renoncer à rapport un bug ou de proposer un correctif, par ce que j'étais en train de faire autre chose en même temps et que j'avais la flemme de créer un compte sur un n-ième site (oui je sais, c'est pas bien).
Ceci dit, le dépôt de Cover Thumbnailer sur Launchpad (qui était le lieu où était développé ce logiciel avant que je migre tous mes dépôts sur Github) est toujours automatiquement synchronisé avec le dépôt Github. Donc on a quand même des backups. :)
En fait j'ai migré le dépôt de Cover Thumbnailer sur Github en Juin 2017, c'est pas tout à fait nouveau donc. :)