J'aime le style de github. Certes, c'est un peu lent, mais toutes les fonctions utiles tombent sous la main. C'est simple, clair et direct. La plupart des variantes ne font que compliquer les choses.
En tant que mec qui maintient des projets libres (sur Github ou pas), j'ai autre chose Ă faire que de surveiller mes mails pour voir si y'aurait pas un patch Ă relire qui aurait atterri sur une mailing list. D'autant plus si l'auteur dudit patch n'a pas l'intention de prendre en compte les commentaires faits par les relecteurs.
# L'a-t-il été?
Posté par freem . Évalué à  2.
Perso, j'aimais bien bitbucket avant qu'ils ne s'amusent a essayer de copie github, mais le résultat a été que le site est passé de plus rapide a consulter (et pas quun peu) à tellement plus lent, avec moins de projets dessus. Ah, ce très cher diable n'a pas fini de nous emmerder.
Ironiquement, sourceforge le mort est lui, toujours utilisé par pas mal de projets pour héberger les release. Bon, j'ai link vers un seul projet, mais il s'agit d'un projet né après la «mort» de SF, né sur github, qui a, en bien moins d'années d'existence que SF quand on l'a déclaré à fuir, mangé un bel exode (pas de ref, ici, dommage, juste un sentiment, mais c'est p'tet juste a cause du vacarme que quelques-un ont causé).
Bref, a mes yeux, github, gitlab, atlassian restent des trucs "de hypster", SF le mort reste ma référence en terme de qualité pour qui recherche un projet auquel participer, de truc facile a utiliser.
À moins que je ne me trompe, github ne supporte toujours pas les ML, par exemple, et si la diffusion de release est régulièrement préférée via SF (malgré les problèmes du passé), il doit y avoir une raison.
Pour ma part, j'ajouterais Ă©galement que le principe du "fork the original, then clone on your system, then branch, then push, then re-push, then hope" promu par github est franchement douteux, et encourage a beaucoup de blabla mĂŞme pour un patch de moins de 15 lignes.
Depuis quelques expériences, en fait, j'ai arrêté de contribuer sur un projet qui n'a pas de canal "libre" style irc ou ML, surtout ML. La latence avec les sites type github est bien pénible, et le moindre correctif de patch est bien trop laborieux, nettement plus qu'envoyer un patch par mail.
[^] # Re: L'a-t-il été?
Posté par nlgranger . Évalué à  3.
J'aime le style de github. Certes, c'est un peu lent, mais toutes les fonctions utiles tombent sous la main. C'est simple, clair et direct. La plupart des variantes ne font que compliquer les choses.
Je ne comprend pas ce qui te déplaît dans les pull request (ou était-ce un troll bien déguisé?): ça s'intègre bien avec git, avec le processus de revue de code, avec les tests automatiques, et ça permet de travailler de manière incrémentale en suivant les évolutions de la branche principale si jamais l'intégration prend du temps.
En fait, c'est juste un coup de main à prendre: tu peux par exemple toujours suggérer un patch, mais dans un rapport de bug: c'est équivalent à un mail sur la mailing list sauf qu'il y a un suivi ouvert/clôturé en plus.
Et c'est plus facile de naviguer/rechercher/filter dans les pages de bugs, pull requests que dans une mailing list.
Le principal défaut amha, c'est le côté facebook avec la nécessité d'avoir un compte pour contribuer, gitlab ou atlassian sont plus flexibles de ce point de vue.
[^] # Re: L'a-t-il été?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à  4.
En tant que mec qui maintient des projets libres (sur Github ou pas), j'ai autre chose Ă faire que de surveiller mes mails pour voir si y'aurait pas un patch Ă relire qui aurait atterri sur une mailing list. D'autant plus si l'auteur dudit patch n'a pas l'intention de prendre en compte les commentaires faits par les relecteurs.
On a des patchs qui ont plus de 5 ans et qui sont encore en train de murir doucement sur notre outil de suivi. C'est hors de question de gérer ça avec une mailing list.
Il faut se rendre compte que la facilité de cette appruche pour toi qui contribue occasionellement à un projet, c'est du boulot en plus pour les mainteneurs du projet en question (soit pour suivre les patchs à la main, soit pour mettre en place et maintenir un outil de suivi).
Visiblement github a visé juste, pour des projets petits ou moyens, leur approche fonctionne très bien. Et pour les gros, ben ils peuvent se permettre de maintenir leurs propres outils.
Il reste bien sûr le gros souci que tout se retrouve centralisé sur le même site, le jour ou github va fermer, ça va être rigolo!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.