Categories
Programming

sourcehut – la forge du hacker

sourcehut est un nouveau projet initié par Drew DeVault (notamment connu pour sway). Il s’agit d’une forge composée de différents outils connectés. sourcehut est sous licence GNU Affero General Public License. Principalement programmé en Python (avec le micro-framework Flask). L’interface Web n’utilise pas JavaScript et n’en est pas moins agréable à usiter sur différents types d’écrans.

De prime abord le service peu paraître déroutant et austère. sourcehut est composé de mini-services interconnectés (git.sr.ht pour Git, hg.sr.ht pour Mercurial, todo.sr.ht pour gérer les tickets ou issues, man.sr.ht pour la documentation, builds.sr.ht pour l’intégration continue, lists.sr.ht pour gérer des mailing lists, etc.).

La documentation de sourcehut utilise sourcehut comme par exemple pour Git ou paste. Et les annonces à propos des évolutions régulières de la plateforme se font ici via le service de mailing lists. Bref c’est déjà vraiment très complet et super efficace. sourcehut repose sur un paradigme bien différent de GitHub ou de GitLab.

Pour moi c’est vraiment la forge du hacker. De par son pragmatisme, sa souplesse et le fait qu’elle repose sur des technologies ouvertes. Mais je reviendrai là-dessus plus tard. Attention, sourcehut n’est pas pour le développeur qui compte ces followers ou stars de ces projets. Et ne me faites pas dire ce que je n’ai pas dit. Je pense qu’un aspect un peu plus social pourrait aussi y être intégré. Mais de façon plus saine et pragmatique. Peut être simplement avec un mini-service de communication synchrone (contrairement aux emails) inter-équipe.

Une différence majeure entre sourcehut et GitHub réside dans l’usage de Git. Particulièrement le processus de contribution à des projets. Tout le monde connaît bien les pull requests. Et bien avec sourcehut c’est beaucoup plus simple. Vous travaillez localement sur votre branche de votre propre dépôt (ou fork) et vous pouvez contribuer (en upstream) simplement en envoyant un patch par email. Oui je vous entend, mais lisez la suite avant de réagir comme ça. Des milliers de contributeurs de Linux et d’autres gros projets travaillent de cette manière encore aujourd’hui. En fait Git a été conçu pour travailler de cette manière. Envoyer des patchs par email en 2019 peut paraître old school, mais pour avoir essayé je peux vous dire que c’est vraiment simple et même plus rapide que de passer par une interface Web. Dans mon cas j’ai utilisé cette extension Git qui permet d’envoyer un set de commits en upstream par email. Et une fois l’extension bien configurée, il suffit par exemple de taper git send-email HEAD~2. Qui en quelques sortes est l’équivalent d’une pull request sur GitHub. Ensuite le mainteneur peut appliquer le patch. Aussi l’avantage de l’email pour contribuer à des projets est que vous utilisez des technologies open source. Vous pouvez ainsi utiliser des clients comme Thunderbird ou KMail. Ou directement SMTP si vous utilisez le module Git send-email. Et comme on peut le voir, il est naturellement possible de discuter sur un patch soumis avant qu’une contribution soit acceptée. Comme une discussion sur GitHub. Sauf que ces discussions je peux les suivre depuis KMail et y prendre part sans ouvrir mon navigateur Web. Alors certes, j’aime beaucoup ce navigateur Web qui est Firefox. Mais ces derniers temps il est beaucoup utilisé pour interagir avec des services propriétaires. Et je trouve ceci assez ironique. Le fait qu’une bonne veille application de bureau permette finalement de communiquer en utilisant des standards, dans le cadre de contributions à des projets open source. Bon, c’est un autre sujet…

Pour finir ce que je trouve assez rigolo avec le service sourcehut (sr.ht), c’est la page pricing. C’est exactement mon esprit. Je n’ai jamais dépensé un cent pour GitHub ou GitLab alors que je contribue déjà financièrement à sourcehut. Pour l’instant à hauteur de 50 euros par an. Et si nécessaire je n’hésiterai pas à donner plus.

Categories
FLOSS

Git a gagné, et on le savait déjà.

Eric S. Raymond pense la même chose que moi à propos de Git et Mercurial, il semble.

” git won the mindshare war. I regret this – I would have preferred Mercurial, but it too is not looking real healthy these days. I have made my peace with git’s victory and switched. I urge the Emacs project to do likewise.” 

bzr is dying; Emacs needs to move, 02 Jan 2014.

J’avais commencé par apprendre Mercurial (parce que Python), puis Git. Je préfère également l’interface utilisateur de Mercurial et trouve Mercurial un peu plus simple d’utilisation. Tout comme esr j’accepte la victoire de Git, qui est indéniablement un excellent DVCS. Techniquement Git a effectivement quelques avantages. Je vois surtout la gestion des branches qui est certainement mieux pensée et la zone de transit (ou staging, que l’on peut retrouver avec DirState en utilisant Mercurial).

Les statistiques Ohloh confirment la victoire de Git sur Mercurial. La décision de l’équipe de Bitbucket en 2011 de supporter Git était donc judicieuse afin de sécuriser leur avenir.

Bref, Git semble bien lancé pour écraser toutes concurrences. Ce qui est bien dommage car j’aime la diversité. Je trouve sympa le fait d’utiliser Mercurial pour un projet, Git pour un autre et Bazaar encore pour un autre. L’avenir de Bazaar est très certainement compromis. À un peu plus long terme celui de Mercurial (utilisé par la fondation Python). C’est en partie pour cette raison que mon activité sur Gitorious augmente depuis quelques temps. Il faut savoir quand il est inutile de s’obstiner.

Le threadbzr is dying; Emacs needs to move” de la liste de diffusion emacs-devel montre à quel point un outil comme un système de versionnement a son importance dans le développement d’un logiciel. Le passage à Git est une première étape afin d’apporter du sang neuf dans la communauté d’Emacs. En 2013/2014 pour un projet open source, avoir un dépôt sur Github est quasiment un prérequis pour son succès. Mais c’est un autre problème à développer.

Categories
Internet Life

TED de Clay Shirky: How the Internet will (one day) transform government

Encore un excellent discours TED, How the Internet will (one day) transform government. Cette fois-ci de Clay Shirky.

Categories
Science

À lire et à écouter

Voici deux liens intéressants:

  1. Gödel and the limits of logic;
  2. ESR at Philly JUG.

Le premier est un article très intéressant sur Gödel. D’ailleurs l’auteur de l’article me rappel l’intervenant d’une petite conférence sur Alan Türing, à laquelle j’ai assisté il y a quelques temps.
Le second est une vidéo d’Eric Steven Raymond (ESR) sous forme de questions/réponses, de manière informelle. Il parle notamment du mouvement open-source et des languages fonctionnels. De plus selon lui, la GPLv3 est maintenant moins nécessaire, car nous avons gagné.