Et un bugtracker, et un wiki (de mémoire) et un httpd…
Pour moi, si on veut une vraie comparaison, il faut comparer fossil à redmine+git, ou gitlag+git, ou whatever+svn, truc+mercurial, foo+bar.
On peut utiliser fossil comme un simple DVCS, mais on perds dans ce cas l'un des intérêts majeurs de la bête.
Je pense que c'est un peu un outil hors concours en fait. Pour moi, si quelqu'un à besoin un jour d'héberger un projet unique sans chercher à séduire pleins de contributeurs, fossil est superbe.
Admettons quelqu'un qui se crée un BSD (parce qu'ils ont tout le code de tous leurs binaires dans un repo unique), par exemple, je pense que fossil sera un excellent choix (facilité de clonage avec les bugs inclus, on pourrais même imaginer (je suis pas sûr que ça soit faisable) de merger la liste des tickets comme moyen de reporter un bug, pas de dépendance à un dépôt tiers…).
Je crois me souvenir que fossil est par exemple utilisé par sqlite3, qui à très peu (aucune?) de dépendances externes.
Par contre, si on cherche à juste faire un jeu vidéo, je pense que github, gitlab, sourceforge sont plus appropriés, ne serait-ce que parce que la plupart des développeurs ont déjà un compte sur au moins une de ces plate-formes, et qu'il est probable que les autres projets dont on dépends (genre, une lib pour gérer l'interface) seront probablement sur la même, et du coup ça simplifie les échanges.
Je n'ai jamais vraiment considéré github comme une forge, mais juste comme un ensemble de repo mit bout à bout…
Bon, j'avoue que mon opinion est de moins en moins tenable, mais dans une forge telle que trac, il est aisé, du fait de la centralisation des tickets, de remonter un ticket au projet qui a le réel problème. Enfin, si le projet en question est hébergé par la même forge et sur le même nom de domaine….
Tout dépend du comment. Dans une forge qui mets en vraie relation plusieurs projets, on peut mettre un ticket comme étant dépendant de la résolution de plusieurs projets liés, et qu'il soit résolu automatiquement lors de la cloture de ces derniers.
Ça va au-delà du simple lien http(s)…
plus puissant que ce qu'on trouve dans gogs ou gitlab
Ça tombe bien, j'ai parlé de redmine, j'ai toujours détesté les forges git-only, github la 1ere.
L'usage du SQL peut être un réel bénéfice, si et seulement si c'est bien documenté, mais ça implique aussi qu'il faille un dev pour gérer ça, ce qui a un coût en entreprise. En revanche, c'est un coût en moins dans un environnement sans admin, juste des devs dont 1 qui aime les SGBDR.
J'ai pas compris de quoi tu parle pour la dépendance PHP ? On peut faire des références entre tickets et commits dans Fossil, ou même référencer des liens externes, et encore mieux on peut lier des "tech notes" au commits ou dans la timeline pour expliquer plus longuement que dans un message de commit.
Je parlais de lier un ticket à un autre ticket d'un autre projet?
Fossil est écrit en C aussi donc j'ai pas compris ?
Justement, c'est un des points qui font qu'il m'attire. Tu as oublié de mettre en exergue le point que tu ne comprend pas?
"git reset" par exemple a un comportement très différent selon les options, ça devrait être plusieurs commandes séparées, etc. Tout est très tarabiscoté je trouve.
Ma foi, je suis assez d'accord avec toi si je prend la totalité de mon expérience avec git. Ceci était dit, la totalité implique de prendre en compte mon apprentissage initial il y a 8 ans, je pense.
Depuis, porcelain git s'est amélioré et fournit bien souvent des info sur ce que tu veux vraiment faire, mais il est vrai que je ne l'exploite pas à fond.
Par exemple, le reste, j'aimerai que tu développes?
Resultat: Borland coulé, netbeans open sourcé et moribond et Eclipse idem. IntelliJ avec son double licensing avance.
Borland, ça fait des années que j'en ai pas entendu parler, c'est vrai.
Mais, Eclipse, ça semble rester très populaire, pour ma part je lui ai préféré netbeans pour sa stabilité et ses perfs quand j'ai du me fader du java compatible eclipse, mais intelliJ je connais que de nom.
Du coup, tu pourrais m'expliquer?
Notes que je suis plus orienté C et C++, avec un p'tit coup de bourne par-ci, par-là.
Rational ne vaut plus rien aujourd'hui et ils misent tout sur le cloud.
Mince, j'en garde pourtant un excellent souvenir de BTS… y'a 12 ans, merde, ça commence à piquer… mais ça douillait trop pour un amateur, et j'étais déjà plus trop fan des cracks. POurtant, ça semble encore vivant, et vendu à prix d'or?
Maintenant, quel impact pour nous (libristes)? Je dirais que l'on doit s'attendre à une chute des contributions dans tous les projets FOSS sur lesquels RedHat était actif, et plus particulièrement sur tous les projets qui ne concernent pas directement les raisons pour lesquelles IBM a acheté RedHat.
Dans les années 2000 je crois, ils ont revendu leur division PC fixes me semble, donc du coup, ils doivent se concentrer sur le matos et les services pro: serveurs et cloud.
Pour le coup, ça colle avec RH je trouve, qui eux aussi ont fait des pubs à la télé dans les années 90-2000 je crois? mais qui surtout ciblent le marché pro, par le particulier.
Ça se tiens.
Maintenant, il reste le problème devant la multiplication des lois et des humains par kilomètre carré de trouver et de payer assez de monde capable de connaître la totalité des lois, d'avoir la patience d'écouter chaque cas, voire de mener des enquêtes pour rendre une justice équitable.
Plus j'y pense, moins j'ai d'opinions sur le sujet de ce qu'il faudrait faire.
D'un côté j'aime le fait que l'accuseur soit celui qui défense le fait que le suspect soit coupable, mais justement, les automates fournissent en théorie et sans compromission cette preuve de manière pseudo-automatique… vraiment, je ne sais pas.
Juste, sur ce point, pourrais-tu expliciter un peu plus sur l'intérêt?
Si j'avais du choisir un DVCS de toutes façons ça aurait plutôt été mercurial ou autre mais jamais Git, son utilisation est bien trop complexe et les risques de perdre du taf trop importants.
Je suis intrigué la. Sans vouloir lancer le troll, j'admets avoir adopté git pour 2 raisons principales:
écrit en langage natif (si, ça compte, sur des systèmes pas top, et j'ai d'abord découvert le VCS pour mes loisirs, et ensuite ai cherché à les faire adopter dans mes tafs);
populaire, donc plus de doc;
Du coup, je serais curieux de voir des cas pratiques ou Mercurial est plus simple? Notamment quand l'on vient de SVN (apprendre git à déjà été douloureux, malgré que j'aie toujours vu ses avantages, sinon me serais pas fait chier: c'était juste mes projets perso après tout)
Par contre, j'ai toujours eu une certaine tendresse pour fossil, sans jamais trouver vraiment de raisons de le plébisciter…
Pour faire simple, fossil, c'est pas un DVCS, c'est une forge légère.
Tant qu'un projet est indépendant et pas accompagné de bibliothèques semi-externes, c'est probablement la plus adaptée des situations, à conditions de vouloir rester maître de sa forge.
Les avantages et les défauts sont multiples.
Utiliser fossil implique une isolation totale des projets dont on pourrait dépendre. La news parle de dépendance à PHP? Bon. Si à un moment donné, un workaround est construit autour d'un bug d'une certaine version de PHP, comment référencer facilement le ticket sur la dépendance? Impossible.
D'un autre côté, les choses comme le wiki et le bugtrackers sont clonés en même temps que le répo.
On peut aussi citer le fait que, justement, fossil soit tout en un. Donc, on doit se restreindre à cet outil qui est quand même limité en terme de fonctionnalités pour gérer les tickets, un site web, etc.
Franchement, fossil est largement supérieur en terme de fonctionnalités à git. Mais, git, lui, ne fait qu'une seule chose, la fait bien et peut être intégré dans d'autres outils spécialisés dans leur domaine comme redmine.
Pour moi, les deux approches sont intéressantes, même si j'avoue n'avoir que peu exploité fossil.
autant utiliser ce moyen de transport qui ne pollue plus.
Dommage quand même que le moyen de diffusion pollue tant… entre l'encodage des vidéo, leur transport sur la toile et le décodage sur fond de HTML5, la quantité d'énergie gâchée est phénoménale comparée à un simple texte accompagné d'images et schémas.
Et si la vidéo est si géniale, je tiens à informer que, pour info, sur mon CPU actuel, télécharger une vidéo via wget et la lire via mpv ne déclenche pas mon ventilo, mais utiliser firefox (par exemple) pour la lire, si.
Ce que je veux dire par la, ce n'est pas que l'écolo moyen doit se passer des vidéos sur le net, hein, juste qu'un véritable écolo permettra le téléchargement isolé aisé de celle-ci.
D'autre part, une vidéo est nécessairement plus coûteuse (sans même parler de HD) qu'un série d'images entrecoupées de texte explicatif, ne serait-ce que parce que celui qui suit n'aura pas à infliger à sa machine de gros calculs pour revenir en arrière avec une image cohérente.
Tout ceci étant dit, je trouve la chose intéressante, puisque ça permets aussi de faire (re)découvrir certains trucs et astuces, parce que c'est pas parce que les technos sont connues des historiens qu'elles ont été appliquées récemment.
[^] # Re: Fossil
Posté par freem . En réponse à la dépêche Sortie de Garradin 0.9 : recherche avancée, exportation ODS, etc.. Évalué à 2. Dernière modification le 30 octobre 2018 à 19:59.
Et un bugtracker, et un wiki (de mémoire) et un httpd…
Pour moi, si on veut une vraie comparaison, il faut comparer fossil à redmine+git, ou gitlag+git, ou whatever+svn, truc+mercurial, foo+bar.
On peut utiliser fossil comme un simple DVCS, mais on perds dans ce cas l'un des intérêts majeurs de la bête.
Je pense que c'est un peu un outil hors concours en fait. Pour moi, si quelqu'un à besoin un jour d'héberger un projet unique sans chercher à séduire pleins de contributeurs, fossil est superbe.
Admettons quelqu'un qui se crée un BSD (parce qu'ils ont tout le code de tous leurs binaires dans un repo unique), par exemple, je pense que fossil sera un excellent choix (facilité de clonage avec les bugs inclus, on pourrais même imaginer (je suis pas sûr que ça soit faisable) de merger la liste des tickets comme moyen de reporter un bug, pas de dépendance à un dépôt tiers…).
Je crois me souvenir que fossil est par exemple utilisé par sqlite3, qui à très peu (aucune?) de dépendances externes.
Par contre, si on cherche à juste faire un jeu vidéo, je pense que github, gitlab, sourceforge sont plus appropriés, ne serait-ce que parce que la plupart des développeurs ont déjà un compte sur au moins une de ces plate-formes, et qu'il est probable que les autres projets dont on dépends (genre, une lib pour gérer l'interface) seront probablement sur la même, et du coup ça simplifie les échanges.
[^] # Re: Fossil
Posté par freem . En réponse à la dépêche Sortie de Garradin 0.9 : recherche avancée, exportation ODS, etc.. Évalué à 0.
Il est où, le sujet+verbe+complément?
Les points de suspension, c'est 3 points, pas 4. Et puis, y'a un caractère spécial pour ça.
[^] # Re: Évolution
Posté par freem . En réponse au journal Enfin un maire qui a la tête sur les épaules. Évalué à 4.
D'autant qu'avec les ondes électromagnétiques, les centrales nucléaires et les OGM, ce jour s'approche dangereusement :p
/me ->[]
[^] # Re: Chasseur myope ?
Posté par freem . En réponse au journal Enfin un maire qui a la tête sur les épaules. Évalué à 2. Dernière modification le 30 octobre 2018 à 19:44.
Heureusement, il y à:
Du coup la sanction me parait à peu près correcte.
Ce qui est logique.
[^] # Re: Ma solutions dans ce genre de soucis
Posté par freem . En réponse au message [ordinosaure] Disque dur non trouvé au boot. Évalué à 2.
Du coup, une suggestion supplémentaire de distro réputée pour supporter du vieux matos? J'avoue ne pas avoir fait d'essais ce soir…
[^] # Re: Microsoft en rêvait
Posté par freem . En réponse au journal IBM achète Red Hat. Évalué à 2.
Je proteste, tu es l'original:
M'enfin,les grands esprits se rencontrent, comme on dit :)
[^] # Re: Fossil
Posté par freem . En réponse à la dépêche Sortie de Garradin 0.9 : recherche avancée, exportation ODS, etc.. Évalué à 2.
Je n'ai jamais vraiment considéré github comme une forge, mais juste comme un ensemble de repo mit bout à bout…
Bon, j'avoue que mon opinion est de moins en moins tenable, mais dans une forge telle que trac, il est aisé, du fait de la centralisation des tickets, de remonter un ticket au projet qui a le réel problème. Enfin, si le projet en question est hébergé par la même forge et sur le même nom de domaine….
[^] # Re: Fossil
Posté par freem . En réponse à la dépêche Sortie de Garradin 0.9 : recherche avancée, exportation ODS, etc.. Évalué à 2.
Tout dépend du comment. Dans une forge qui mets en vraie relation plusieurs projets, on peut mettre un ticket comme étant dépendant de la résolution de plusieurs projets liés, et qu'il soit résolu automatiquement lors de la cloture de ces derniers.
Ça va au-delà du simple lien http(s)…
[^] # Re: Soyez nombreux
Posté par freem . En réponse au lien Meeting de la République en direct à commenter en direct sur la tribune https://linuxfr.org/board. Évalué à 2.
Enfin un usage pertinent des liens!
[^] # Re: Mauvaise nouvelle
Posté par freem . En réponse au journal IBM achète Red Hat. Évalué à 4.
Si c'est rentable, pourquoi ça serait une mauvaise nouvelle pour linux en entreprise?
Si IBM n'est pas philanthropique, que RH est rentable, et que le libre est rentable, pourquoi changer de politique?
Quels engagements, exactement?
[^] # Re: Fossil
Posté par freem . En réponse à la dépêche Sortie de Garradin 0.9 : recherche avancée, exportation ODS, etc.. Évalué à 2.
Ça tombe bien, j'ai parlé de redmine, j'ai toujours détesté les forges git-only, github la 1ere.
L'usage du SQL peut être un réel bénéfice, si et seulement si c'est bien documenté, mais ça implique aussi qu'il faille un dev pour gérer ça, ce qui a un coût en entreprise. En revanche, c'est un coût en moins dans un environnement sans admin, juste des devs dont 1 qui aime les SGBDR.
Je parlais de lier un ticket à un autre ticket d'un autre projet?
[^] # Re: Fossil
Posté par freem . En réponse à la dépêche Sortie de Garradin 0.9 : recherche avancée, exportation ODS, etc.. Évalué à 4.
Justement, c'est un des points qui font qu'il m'attire. Tu as oublié de mettre en exergue le point que tu ne comprend pas?
Ma foi, je suis assez d'accord avec toi si je prend la totalité de mon expérience avec git. Ceci était dit, la totalité implique de prendre en compte mon apprentissage initial il y a 8 ans, je pense.
Depuis, porcelain git s'est amélioré et fournit bien souvent des info sur ce que tu veux vraiment faire, mais il est vrai que je ne l'exploite pas à fond.
Par exemple, le reste, j'aimerai que tu développes?
[^] # Re: Proverbe du jour
Posté par freem . En réponse au journal IBM achète Red Hat. Évalué à 1.
J'aurai dit que ça sent le cuvé, vu le côté arguments de comptoirs.
[^] # Re: Microsoft en rêvait
Posté par freem . En réponse au journal IBM achète Red Hat. Évalué à 4.
Borland, ça fait des années que j'en ai pas entendu parler, c'est vrai.
Mais, Eclipse, ça semble rester très populaire, pour ma part je lui ai préféré netbeans pour sa stabilité et ses perfs quand j'ai du me fader du java compatible eclipse, mais intelliJ je connais que de nom.
Du coup, tu pourrais m'expliquer?
Notes que je suis plus orienté C et C++, avec un p'tit coup de bourne par-ci, par-là.
Mince, j'en garde pourtant un excellent souvenir de BTS… y'a 12 ans, merde, ça commence à piquer… mais ça douillait trop pour un amateur, et j'étais déjà plus trop fan des cracks. POurtant, ça semble encore vivant, et vendu à prix d'or?
[^] # Re: Mauvaise nouvelle
Posté par freem . En réponse au journal IBM achète Red Hat. Évalué à 4.
Pourquoi le libre ne serait-il par rentable?
Ne serait-ce que pour la réputation, ça me semble l'être….
[^] # Re: Microsoft en rêvait
Posté par freem . En réponse au journal IBM achète Red Hat. Évalué à 2.
Merde, j'ai sorti la même avant de lire ton com….
[^] # Re: Microsoft en rêvait
Posté par freem . En réponse au journal IBM achète Red Hat. Évalué à 2.
SystemD?
Hop moi…
[^] # Re: Microsoft en rêvait
Posté par freem . En réponse au journal IBM achète Red Hat. Évalué à 4.
Dans les années 2000 je crois, ils ont revendu leur division PC fixes me semble, donc du coup, ils doivent se concentrer sur le matos et les services pro: serveurs et cloud.
Pour le coup, ça colle avec RH je trouve, qui eux aussi ont fait des pubs à la télé dans les années 90-2000 je crois? mais qui surtout ciblent le marché pro, par le particulier.
[^] # Re: Microsoft en rêvait
Posté par freem . En réponse au journal IBM achète Red Hat. Évalué à 5.
Ben, si on écoute certains, un certain Lennart employé par RH à toujours voulu tuer le LL, alors bon….
[^] # Re: mauvais titre, changer titre
Posté par freem . En réponse au journal Enfin un maire qui a la tête sur les épaules. Évalué à 2.
Ça dépend de si Saturne passe assez près du gibier pour faire perdre la tête au maire.
[^] # Re: Chasseur myope ?
Posté par freem . En réponse au journal Enfin un maire qui a la tête sur les épaules. Évalué à 2.
Et pour l'anecdote, ça s'est fini comment? Parce que, pour le moment, c'est plutôt à charge des chasseurs de mon point de vue.
[^] # Re: Hum...
Posté par freem . En réponse au journal Le VAE n'est PAS un truc de fainéant. Évalué à 2. Dernière modification le 29 octobre 2018 à 20:31.
Ça se tiens.
Maintenant, il reste le problème devant la multiplication des lois et des humains par kilomètre carré de trouver et de payer assez de monde capable de connaître la totalité des lois, d'avoir la patience d'écouter chaque cas, voire de mener des enquêtes pour rendre une justice équitable.
Plus j'y pense, moins j'ai d'opinions sur le sujet de ce qu'il faudrait faire.
D'un côté j'aime le fait que l'accuseur soit celui qui défense le fait que le suspect soit coupable, mais justement, les automates fournissent en théorie et sans compromission cette preuve de manière pseudo-automatique… vraiment, je ne sais pas.
[^] # Re: Fossil
Posté par freem . En réponse à la dépêche Sortie de Garradin 0.9 : recherche avancée, exportation ODS, etc.. Évalué à 3.
Juste, sur ce point, pourrais-tu expliciter un peu plus sur l'intérêt?
Je suis intrigué la. Sans vouloir lancer le troll, j'admets avoir adopté git pour 2 raisons principales:
Du coup, je serais curieux de voir des cas pratiques ou Mercurial est plus simple? Notamment quand l'on vient de SVN (apprendre git à déjà été douloureux, malgré que j'aie toujours vu ses avantages, sinon me serais pas fait chier: c'était juste mes projets perso après tout)
Par contre, j'ai toujours eu une certaine tendresse pour fossil, sans jamais trouver vraiment de raisons de le plébisciter…
[^] # Re: Fossil
Posté par freem . En réponse à la dépêche Sortie de Garradin 0.9 : recherche avancée, exportation ODS, etc.. Évalué à 4. Dernière modification le 29 octobre 2018 à 20:20.
Pour faire simple, fossil, c'est pas un DVCS, c'est une forge légère.
Tant qu'un projet est indépendant et pas accompagné de bibliothèques semi-externes, c'est probablement la plus adaptée des situations, à conditions de vouloir rester maître de sa forge.
Les avantages et les défauts sont multiples.
Utiliser fossil implique une isolation totale des projets dont on pourrait dépendre. La news parle de dépendance à PHP? Bon. Si à un moment donné, un workaround est construit autour d'un bug d'une certaine version de PHP, comment référencer facilement le ticket sur la dépendance? Impossible.
D'un autre côté, les choses comme le wiki et le bugtrackers sont clonés en même temps que le répo.
On peut aussi citer le fait que, justement, fossil soit tout en un. Donc, on doit se restreindre à cet outil qui est quand même limité en terme de fonctionnalités pour gérer les tickets, un site web, etc.
Franchement, fossil est largement supérieur en terme de fonctionnalités à git. Mais, git, lui, ne fait qu'une seule chose, la fait bien et peut être intégré dans d'autres outils spécialisés dans leur domaine comme redmine.
Pour moi, les deux approches sont intéressantes, même si j'avoue n'avoir que peu exploité fossil.
[^] # Re: C'est pas si mal
Posté par freem . En réponse à la dépêche Financement participatif de Low‐tech Lab. Évalué à 3.
Dommage quand même que le moyen de diffusion pollue tant… entre l'encodage des vidéo, leur transport sur la toile et le décodage sur fond de HTML5, la quantité d'énergie gâchée est phénoménale comparée à un simple texte accompagné d'images et schémas.
Et si la vidéo est si géniale, je tiens à informer que, pour info, sur mon CPU actuel, télécharger une vidéo via wget et la lire via mpv ne déclenche pas mon ventilo, mais utiliser firefox (par exemple) pour la lire, si.
Ce que je veux dire par la, ce n'est pas que l'écolo moyen doit se passer des vidéos sur le net, hein, juste qu'un véritable écolo permettra le téléchargement isolé aisé de celle-ci.
D'autre part, une vidéo est nécessairement plus coûteuse (sans même parler de HD) qu'un série d'images entrecoupées de texte explicatif, ne serait-ce que parce que celui qui suit n'aura pas à infliger à sa machine de gros calculs pour revenir en arrière avec une image cohérente.
Tout ceci étant dit, je trouve la chose intéressante, puisque ça permets aussi de faire (re)découvrir certains trucs et astuces, parce que c'est pas parce que les technos sont connues des historiens qu'elles ont été appliquées récemment.