• [^] # Re: Tard

    Posté par (site web personnel, Mastodon) . En réponse au journal GNOME va passer à GitLab. Évalué à 10.

    GNOME va enfin avoir une CI

    GNOME avait déjà de l'intégration continue, comme dit dans un autre commentaire. Et divers projets avaient aussi leur propre serveur (par exemple, GIMP a son serveur Jenkins).
    Ensuite je dis pas, un truc intégré au bugtracker, qui va aussi tester des commits hors master (j'imagine que c'est surtout ça l'intérêt), c'est bien. On n'a pas, en effet. Mais dire qu'y avait rien du tout n'est pas vrai pour autant.

    Même le noyau avait fait des efforts pour être disponible sur GitHub.

    De mémoire, le noyau avait placé un miroir sur Github parce qu'ils avaient eu des problèmes qui ont rendu leur instance principale non disponible (souvenir confirmée par une recherche web). À ce jour, ce n'est qu'un miroir lecture seul et aucune contribution n'y est acceptée (voir tous les "pull requests" où un bot poste automatiquement pour demander aux gens de passer par le processus normal).
    GNOME a exactement la même chose: https://github.com/gnome/
    Il y a des miroirs Github de tous les projets hébergés par GNOME en lecture seul, et n'acceptant pas les contributions. Je ne vois pas de différence.

    Il y a encore beaucoup de projets majeurs qui utilisent des forges internes assez fermées à l'extérieur

    Euh... en quoi le bugzilla actuel est "fermé" à l'extérieur? Il ne l'est pas, ou alors tout autant que n'importe quel projet sur Github où il faut simplement un compte.

    ou en tout cas avec une marche assez haute à surmonter pour juste contribuer.

    Je ne comprends absolument pas cet "argument". En quoi une instance gitlab va changer quoi que ce soit à la "marche" pour contribuer? Cette marche sera et a toujours été simplement "créer un compte". Ce sera toujours le cas avec Gitlab. En outre, si tu trouves cela une marche "haute", je me demande bien ce qu'est une marche pas haute. Les listes de discussion (comme pour contribuer au Kernel) n'ont pas cette marche (on n'est pas forcé de s'inscrire pour envoyer un email à la LKML), ok. Mais tout ceux qui ont une "forge" ont l'étape d'inscription et Github n'est pas épargné.

    Bon je fais l'idiot, en vrai je comprends bien ce que tu dis. Tu veux dire que tu as déjà créé un login sur github donc tu n'as pas besoin d'en refaire un pour un projet qui y est déjà? Déjà on pourrait dire la même chose de GNOME (y a des centaines de projets là-bas et largement de quoi faire aussi; en fait de nos jours, les rares projets sur lesquels je contribue sur Github auraient pu avoir leur instance chez GNOME ou FreeDesktop, voire l'ont eu et ont déménagé pour suivre le hype; et c'est en fait eux qui me font chier pour le coup). En outre tout centraliser n'est absolument pas la solution. Y a 10 ans, on disait la même chose de Sourceforge que Github de nos jours. On voit ce que c'est devenu, entre les pubs, malware et mauvaises pratiques. Entre les deux, y a aussi eu Google Code que certains ont cru être le nouveau Graal. Ça a fermé depuis. Etc. Les gens n'apprennent pas et continuent à confier leurs données à des sociétés qui n'ont aucun scrupule et les abandonnent ou vendent leurs données du jour au lendemain.
    L'autre problème est que cela fait chier les gens de créer des comptes pour tout. Je le comprends bien. C'est l'un des problèmes majeurs du web qui n'a pas réussi à se décider sur un standard du login à la OpenID et se repose donc sur des protocoles/implémentations propriétaires (raison pour laquelle j'avais codé l'une des premières implémentation d'identification par XMPP y a des années déjà). Mais dans l'état actuel des choses, pour les raisons citées plus haut, je préfère encore 1000 fois créer 100 comptes sur divers sites et forges que donner toutes mes infos à une seule (ou 2, ou 3) société(s) comme on est amené à le faire de plus en plus de nos jours.

    Je ne suis pas là à dire que le passage à Gitlab est une mauvaise chose. J'en pense certaines bonnes choses, par contre plusieurs autres choses me plaisent moins, notamment dans le workflow (par exemple distinction inutile rapport de bug/soumission de patch, impossibilité de soumettre des patchs en fichier, obligation de faire des branches persos pour des bugs mineurs, la tendance à promouvoir les merges plutôt que les rebases, encourager certains mainteneurs à ne pas tester les patchs en local, car autant une typo de texte peut être accepté en un clic, autant même un changement de code d'une ligne devrait toujours être testée par celui qui accepte le patch, etc.). D'autres sont clairement de bonnes choses (simplification des options pour les nouveaux venus qui sont moins confus par les 1000 options de Bugzilla, une meilleure intégration du code sur le web, une meilleure lecture en ligne du code, la possibilité de commenter des patchs ligne par ligne, accepter les bugs les plus basiques, genre typo, etc. en un clic). Il faut savoir faire la part des choses et aussi voir tous les défauts en dehors du "hype" de ces solutions dont les plus grands avantages pour beaucoup de gens sont en fait simplement leur ressemblance à Github et leur interface plus "moderne". Or la GUI cool et moderne, en vrai, ça passe avec les saisons et les modes. Il faudra voir comment c'est vu dans 10 ans.

    Perso j'attends pour voir. Pour l'instant, je n'ai pas d'avis tranché.

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]