Journal GNOME va passer à GitLab

Posté par  . Licence CC By‑SA.
Étiquettes :
32
18
juil.
2017

Au cours des derniers mois, GNOME a étudié la possibilité de faire évoluer son infrastructure de développement, basé sur le couple cgit‐Bugzilla vers quelque chose de plus moderne, en raison de l’obsolescence de ces derniers (vieillissant, peu d’évolution, peu d’intégration, mauvais workflow…). Au point de faire fuir de potentiels nouveaux contributeurs (personnellement je ne peux que confirmer cela).

Cinq solutions techniques ont été un temps envisagées : GOGS, Gitea, Pagure, Phabricator et GitLab ; rapidement réduites aux deux dernières.

Après une comparaison poussée entre les deux (voir ici), c’est GitLab qui a été choisi, notamment parce que jugé meilleur du point de vue interface (le fait d’être proche de GitHub fut un avantage), ainsi qu’en raison de la présence d’intégration continue.
[Courriel d’Alan Day.]

En revanche, la communauté est invitée à partager ses commentaires et avis, pour ceux qui ont une expérience de l’outil. Une manière d’essayer d’anticiper d’éventuelles surprises ou points bloquants. Mais on imagine très mal que le souhait soit de rester au temps des dinosaures.

Une instance de test a été déployée. À noter que ça semble être la version communautaire qui sera utilisée.

En revanche, la migration complète risque d’être longue et difficile. Des discussions sont aussi en cours pour déterminer le processus. Il semble exclu de migrer tous les bogues de Bugzilla vers GitLab.

  • # Coquilles

    Posté par  (Mastodon) . Évalué à 5. Dernière modification le 18 juillet 2017 à 08:42.

    Il me semble que l'auteur se soit appliqué (notamment sur les accents), alors autant finir le boulot et corriger quelques erreurs :)

    • Cinq solutions techniques ont été un temps envisagées
    • du point de v*u*e interface
    • Par contre la communauté est invitée
    • d'éventuel*le*s surprises
    • la version communautaire qui sera utilisée
    • migrer tou*s* les bugs

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Commentaire supprimé

    Posté par  . Évalué à 6.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Tard

      Posté par  (site web personnel) . Évalué à 5.

      Il me semble qu'il existait déjà GNOME Continuous ( https://wiki.gnome.org/Projects/GnomeContinuous ) au niveau de la CI?

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4.

        Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Tard

      Posté par  (site web personnel, Mastodon) . É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 ]

      • [^] # Re: Tard

        Posté par  . Évalué à 5.

        D'autres sont clairement de bonnes choses (simplification des options pour les nouveaux venus qui sont moins confus par les 1000 options de Bugzilla

        C'est ça, la marche haute. Sérieusement, bugzilla, j'ai essayé de m'en servir pour faire des rapports de bugs sur divers projets, et j'ai systématiquement trouvé l'opération difficile (interface bordélique et trop complexe).
        Moi, perso, l'interface de github, je n'aime pas. Je m'y suis fait, mais je n'aime pas. Celle de bugzilla, je n'aime pas et je n'arrive pas à m'y faire. C'est tout.
        A un moment je préférais l'interface de bitbucket, mais ils l'ont refaite (plusieurs fois) depuis et je n'ai pas encore trop testé. Au final, je pense que ma grande préférée, de toutes celles que j'ai vues, c'est redmine. Alors, certes, on ne peut pas forker et l'intégration du VCS est pas géniale, mais faire un rapport de bugs, cloner le repo, et envoyer un mail avec en pj le patch qui va bien, moi, ça me convient, je trouve ça simple. Je reconnais n'avoir pas vraiment cherché de nouvelles forges du niveau de github, mais de toute façon, pour un projet seul ou groupé avec d'autres, je trouve que github ou bitbucket n'offrent aucun intérêt.
        Leur intérêt, c'est le côté communautaire, nécessaire à leur modèle économique, et ils ont simplement adapté leur interface en fonction de ça. Et côté communautaire, je trouve honnêtement que github ne bat pas encore sourceforge en terme de fonctionnalités (recherche de projets par tags, notamment).

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 10.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Tard

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          Salut,

          Je vois pas pourquoi tu t'énerves. Tu n'as simplement parlé de rien de tout ça dans ton commentaire précédent que j'avais bien lu et auquel j'avais répondu exactement. Tu parlais juste d'absence de CI (ce qui n'est pas vrai, même si probablement la qualité du CI de Gitlab est peut-être beaucoup mieux; je veux bien te croire sur parole étant loin d'être expert), de forge "fermée à l'extérieur" (quoi que cela veuille dire, c'est la seule chose que tu n'expliques pas dans ton nouveau commentaire), et de "marche assez haute" (sans détailler) pour contribuer. C'était des sortes de remarques très générales, et donc j'y répondais en essayant effectivement d'extrapoler puisqu'il n'y avait pas trop de contenu hormis ce que je ressentais (peut-être à tort) comme une sorte de "c'est nul" général auquel je n'adhérais pas.

          Ensuite ton nouveau commentaire est bien plus clair et complet, et je peux comprendre tes divers points maintenant. Si ton premier commentaire avait été aussi complet, je n'aurais pas répondu. Je le dis d'ailleurs aussi dans mon commentaire que Bugzilla est un peu trop complexe, même si je voyais pas cela comme une marche (mais à la réflexion, je comprends, tu as raison d'ailleurs; un autre commentaire a aussi répondu cela d'ailleurs). Pourquoi je parle de création de compte? Encore une fois, j'extrapolais du fait que c'est un classique qu'on nous reproche par rapport à Github (même si c'est idiot) comme étant une marche car les gens veulent pas créer de nouveau compte (alors qu'ils estiment celui de Github comme un "acquis" évident pour un dév apparemment, de même que d'autres estimeraient Facebook comme un acquis, etc.). Désolé. J'essayais juste de deviner ce que pouvait bien signifier "marche assez haute à surmonter pour juste contribuer". Me reprocher de ne pas savoir lire quand c'est tout ce que tu as écrit, c'est un peu dur, tout de même.

          Il n'y a donc vraiment pas besoin de t'offusquer et de faire des attaques de dialectiques STP (les "As-tu lu mon commentaire? Peux-tu me montrer […]" et "lis avant de répondre" qui sont un moyen d'éliminer l'interlocuteur en le faisant passer pour un abruti qui n'a même pas pris la peine de bien lire… en gros c'est ça. En plus de mettre une mauvaise ambiance direct, ce qui franchement n'est pas agréable). Je n'en fais pas, je ne mets aucune ironie ou attaque pernicieuse dans mes commentaires et tu peux compter sur moi pour ne jamais inclure de tournures insultantes dans mes commentaires (ou alors exceptions quand je m'emporte après avoir vraiment vraiment été énervé… je suis humain après tout). Très sérieusement tout ce que je veux, c'est un échange simple et amical. J'espère que tu pourras comprendre cela car je ne souhaite pas continuer une discussion à coup de remarques aigres.

          Voilà. Je préfère mettre les choses au point car j'ai été un peu surpris en me connectant et en voyant ce genre de réponse à un message que j'estimais être plutôt constructif et amical (ou du moins neutre).

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

        • [^] # Re: Tard

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          J'ai pas envie du tout que GNOME soit sur GitHub. Techniquement, je trouve que GitLab est supérieur (sauf les performances), mais surtout, GitLab est vraiment libre (modulo EE).

          Gitlab n'est pas vraiment libre. Tu le dis toi-même dans la parenthèse. Et tu verras que si tu as une utilisation avancée de ta forge, tu vas déchanter du « vraiment libre » Gitlab.

          Jette un coup d'oeil à Tuleap si tu veux une forge moderne vraiment libre.

          • [^] # Re: Tard

            Posté par  . Évalué à 4.

            Gitlab n'est pas vraiment libre. Tu le dis toi-même dans la parenthèse. Et tu verras que si tu as une utilisation avancée de ta forge, tu vas déchanter du « vraiment libre » Gitlab

            Que veux-tu dire ?

            • [^] # Re: Tard

              Posté par  (site web personnel, Mastodon) . Évalué à 4.

              Regarde cette page : https://about.gitlab.com/features/#ee-starter

              Sans même parler de fonctionnalités métier :

              • Support de LDAP ? Pas dans la version "community" (après investigation, visiblement c'est possible… mais du coup leur documentation est trompeuse)
              • Multiple assignees for issues ? Pas dans la version "community"

              En gros, tout est fait pour "acheter la version EE". C'est une stratégie "open core", par opposition à des boîtes qui font du libre et vendent du service.

              Quoi qu'il en soit, dire que "Gitlab est vraiment libre" est une erreur.

              • [^] # Re: Tard

                Posté par  . Évalué à 4.

                Seul les groupes LDAP ne sont pas supporté dans la version communautaire.

                GitLab CE est effectivement vraiment libre. Le fait qu'ils mettent en avant la version entreprise c'est juste ce que font toute entreprise qui vends un produit.

                Il faut quand même préciser que si la version communautaire est à ce niveau-là aujourd'hui c'est parce qu'il y a une rentré d'argent suffisante (via la version entreprise) pour payer des devs à temps plein pour avoir un développement très dynamique (une release majeure par mois environ, plusieurs versions maintenue en parallèles) et ils sont assez ouvert pour pouvoir inclure des fonctionnalités de la version entreprise à la version communautaire. (Récemment les pages)

              • [^] # Re: Tard

                Posté par  (Mastodon) . Évalué à 9.

                Appelons un chat un chat, Gitlab-ce (community edition) est libre (type BSD). Faut juste préciser de quel gitlab on parle. N'importe qui ou boite concurrente pourrait modifier le code pour ajouter les fonctionnalités qui ne sont fournies que dans la version "enterprise".

      • [^] # Re: Tard

        Posté par  (site web personnel) . Évalué à 3.

        bah, un git pull et tu travailles bien comme tu veux sur ton poste :-)

        mais, oui, la mode semble être à la weberie, va falloir s'y faire…

    • [^] # Commentaire supprimé

      Posté par  . Évalué à -3. Dernière modification le 18 juillet 2017 à 12:33.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Tard

        Posté par  . Évalué à 10.

        Tu pourrais être un peu plus précis ?

        Il y a un peu trop de truc qui ont foiré pour que je considère cela comme un accident.

        Pourtant il y a bien eu une erreur humaine, lors des opérations pour remettre la réplication en route, et c’est cette erreur qui a eu la plus grave conséquence.

        Lorsque Gnome passe à GiLab il s’agit du logiciel, pas du service, je ne vois pas trop le rapport entre des lacunes sur l’infrastructure du service et la qualité du logiciel en lui-même. Les cordonniers toussa…

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2. Dernière modification le 18 juillet 2017 à 13:55.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 2.

            Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Tard

            Posté par  . Évalué à 6.

            Et quel est le rapport avec la qualité ou non du code de Gitlab ? Qu'ils fassent des erreurs dans la gestion d'une production, c'est une chose, mais où est-ce que ça incrimine leur code ? Et surtout du coup tu propose quoi comme forge libre ? La quelle propose une instance de prod aussi grosse et depuis aussi longtemps que gitlab pour que tu puisse avoir confiance en leur gestion des risques ?

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Commentaire supprimé

              Posté par  . Évalué à -3.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Tard

                Posté par  . Évalué à 8.

                Je ne vois aucune réponse :

                1. Quelle forge libre possède une prod d'au moins 6 ans avec environ 550 000 projets ce qui est la condition pour comparer ?
                2. Une série de « on sait que », « en général », « la majorité du temps »,… ça n'explique rien.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Tard

            Posté par  . Évalué à 3.

            Il y a toujours une erreur humaine. Tout peu être retracé jusqu'à l'humain dans 99,9% des cas.

            N’importe quel logiciel étant développé par un humain je vois tout à fait ce que tu veux dire. Mais là, il y a bien un humain qui s’est gourré comme il faut, sur un truc très simple : « vider la database répliquée (attention: ne pas vider celle de prod !) »

            Mais étrangement, aucun backup de la vielle n'est prêt en tant que hot spare

            En oubliant les coûts de mise en place, un backup de la veille en hot spare c’est bien un budget × 2 grosso modo (en virtuel comme en physique)  ?

            Il y a peut-être ça en place pour les gens qui payent ;) Je suis complètement d’accord avec ton analyse cela dit.

            il y a un manque de maîtrise dans la résolution d'incident

            Au moins il y a eu de la transparence, on peut pas tout avoir !

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 5.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Tard

              Posté par  . Évalué à 6.

              Euh … en général, dans les sociétés, tu as un service sauvegardes, mais pas de service restauration ( sauf s'il y a une cantine, sinon c des tickets restau).

              • [^] # Re: Tard

                Posté par  . Évalué à 4.

                Bah… « mauvaise société, changer société » j’ai envie de dire…

                Toute bonne entreprise au taquet a un « Plan de Reprise de l’Activité » qui consiste précisément à tester, affiner et maintenir la méthode pour remonter tout le SI (enfin, le cœur de métier, c’est déjà pas mal…) dans le temps le plus court possible.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à -6.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Tard

            Posté par  . Évalué à 8.

            On peut être encore plus global si tu veux :

            • les dev de Gnome consomment de l’oxygène ;
            • l’oxygène fait décoller les fusées ;
            • plusieurs fusées ont connu des dysfonctionnements grave ;
            • les dev de Gnome devraient s’arrêter de respirer.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à -2. Dernière modification le 18 juillet 2017 à 15:59.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Tard

                Posté par  . Évalué à 9.

                Ça fait beaucoup de généralité et d'hypothèses non vérifiée tout ça… C'est très léger pour affirmer qu'ils font du mauvais boulot.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à -10. Dernière modification le 18 juillet 2017 à 17:21.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Tard

                    Posté par  . Évalué à 6.

                    C'est pas du mensonge. C'est toi qui pose des affirmations toutes faites et qui nous balance des hypothèses sans les expliquer. Tu pense bien ce qui t'arrange, mais essaie de l'expliquer.

                    Moi j'aime pas gitlab, mais je me cache pas dans des arguments flous :

                    • les tickets sont trop léger, il n'y a pas de possibilités d'avoir de la recherche aussi fines que sur des gestionnaires comme redmine ou mantis par exemple (et la sauvegarde de filtre n'existe pas non plus par exemple)
                    • la revue de code n'est pas génial je trouve : je n'arrive pas à savoir quel commentaire est associé à quel commit, les commentaires globaux ne peuvent pas avoir de réponse direct (il y a juste une suite de commentaires globaux), etc

                    Je parle de mon ressenti et de ce que je vois dans mon usage.

                    Je pense que c'est mot dernier post ici.

                    C'est un chantage ?

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Tard

                      Posté par  . Évalué à 3.

                      La revue de code sur gitlab, c'est carrément de la merde, surtout quand on a déjà utilisé gerrit, qui lui est vraiment un outil adapté, pas une copie de github (qui est naze aussi) :

                      • Quand on repousse en ayant amendé les patches, les anciens commentaires sont tous simplement perdus… il n'est pas possible de voir si une personne a pris en compte les remarques précédentes car les remarques sont perdues
                      • Gitlab n'a tout simplement pas de notion de revue, juste des commentaires, du coup il envoie un mail pour chaque commentaire qu'on fait, ça spamme bien et en plus :
                        • pas possible pour le destinataire de savoir si la revue d'une personne est finie ou si d'autres commentaires vont arriver de la même personne
                        • pas de mode "brouillon", si on met un commentaire et qu'on se rend compte en lisant quelques blocs plus bas qu'en fait le commentaire n'avait pas lieu d'être, c'est mort, il faut vraiment faire gaffe avant d'écrire le moindre commentaire
                      • Quand quelqu'un vote +1 ou -1 (avec des emojis…) et qu'un patch est modifié, ou ajouté, la note est conservée, alors qu'il faut que la revue du code soit refaite, la note n'est plus d'actualité
                      • Comparer 2 versions d'un commit n'est pas pratique du tout
                      • Accessoirement, pas possible de mettre en surbrillance une portion de texte, un commentaire ne peut concerner qu'une ligne

                      • [^] # Re: Tard

                        Posté par  (site web personnel) . Évalué à 2.

                        Quand on repousse en ayant amendé les patches, les anciens commentaires sont tous simplement perdus… il n'est pas possible de voir si une personne a pris en compte les remarques précédentes car les remarques sont perdues

                        Faux, en tout cas sur une version récente.

                        Quand quelqu'un vote +1 ou -1 (avec des emojis…) et qu'un patch est modifié, ou ajouté, la note est conservée, alors qu'il faut que la revue du code soit refaite, la note n'est plus d'actualité

                        Faux, en tout cas sur une version récente.

                        Comparer 2 versions d'un commit n'est pas pratique du tout

                        Je ne sais pas si c'est ce dont tu parles, puisque par définition dans git il ne peut pas y avoir deux versions d'un commit (dans tout SCM en fait), mais sur une version récente si tu pousses de nouveaux commits dans une branche qui a une merge request en cours, il y a un message dans l'historique de la merge request et on peut voir le diff entre les différents push.

                        Je suis en revanche d'accord sur la dangerosité de l'instantanéité des commentaires.

                        • [^] # Re: Tard

                          Posté par  . Évalué à 3.

                          Faux, en tout cas sur une version récente.

                          Je retesterai voir.

                          Je ne sais pas si c'est ce dont tu parles, puisque par définition dans git il ne peut pas y avoir deux versions d'un commit (dans tout SCM en fait),

                          Supposons une revue avec un commit avec un id 123456 avec un titre "fix crash when user right-clicks". C'est bien, mais le code a un bug. Tu fais un commentaire sur la revue, le dev amende son patch et repousse. Le titre n'a pas changé (ou alors très peu), le but du commit non plus, son id est maintenant 7890ab. Techniquement, ce n'est pas le même commit, mais pourtant 7890ab est bien une "nouvelle version" de 123456.
                          Gerrit gère ça en mettant un identifiant unique dans le message de commit, qui n'est pas censé changer quand on se contente d'amender le patch. Ça permet d'avoir une revue cohérente.

                          Voilà concrètement un exemple pour voir la différence entre "2 versions d'un commit" : (disclaimer : j'ai pris un projet au pif, une revue au pif) https://gerrit.wikimedia.org/r/#/c/280364/1..4/includes/ApiQueryMapData.php
                          Ce n'est pas le meilleur exemple car la revue ne contenait qu'un commit, mais gerrit gère très bien quand il y a plusieurs commit dans le "patchset", quand des patches sont rajoutés dans la nouvelle version du "patchset", etc.

                          • [^] # Re: Tard

                            Posté par  (site web personnel) . Évalué à 2.

                            J'ai un peu la flemme de comprendre l'interface de gerrit (comme quoi on aime ce à quoi on est habitué) mais je suis tenté de confirmer que c'est le "diff de diff" dont je parlais. A ta décharge c'est dispo que depuis une certaine version de Gitlab assez récente.

                    • [^] # Re: Tard

                      Posté par  (site web personnel) . Évalué à -3.

                      barmic c'est pas la première fois que tu es désagréable à chaud ou à froid, et à cause de toi, on va assister au départ de quelqu'un avec qui je discute avec plaisir depuis 15 ans.

                      Tu contribues à une ambiance désagréable sur ce site avec ton ton acerbe et des saillies définitive et c'est particulièrement pénible.

                      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                      • [^] # Re: Tard

                        Posté par  (site web personnel) . Évalué à 2.

                        Mwai, un mec qui ne supporte pas la contradiction quand tout ce qu'il dit est subjectif (en gros, c'est sont avis), il peut partir…

                      • [^] # Re: Tard

                        Posté par  . Évalué à 4.

                        C'est sûr qu'un fil de commentaire comme https://linuxfr.org/users/gnuralph/journaux/data-warehouse#comment-1707156 ou https://linuxfr.org/users/zetrobu/journaux/et-vous-vous-voulez-qu-elle-fasse-quoi-votre-voiture-autonome#comment-1688178 ça respire la bonne ambiance.

                        Il est habitué à commenter sur ce ton, il ne faut pas s'étonner du niveau des réponses que ça génère.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: Tard

                          Posté par  (site web personnel) . Évalué à 3.

                          moui, ce n'est pas pour rien que cela nous avait pris du temps d'accoucher de https://linuxfr.org/regles_de_moderation_du_problematique :/
                          Pour autant, chacun reste maître de ses écrits, de son humeur et de son ressenti par rapport à l'ambiance du site : ce n'est pas que les modos qui en donnent la ligne directrice, c'est ce que chacun y apporte et veut assumer…

                          Bref, avant de faire des commentaires incisifs, autant se rappeler que les smileys par exemple permettent de nuancer le propos ;-) Cela peut permettre de faire passer pour une boutade ce qui apparaîtrait autrement comme une récrimination :p Chacun peut interpréter différemment les traits d'humour :D

                          • [^] # Re: Tard

                            Posté par  . Évalué à -1. Dernière modification le 21 juillet 2017 à 11:21.

                            kikoo, il parait même que ça à été inventé pour ça lol

                            Bon ok je sors :D (oui, je me fait chier royalement la)

                  • [^] # Re: Tard

                    Posté par  (site web personnel) . Évalué à 1.

                    Ce comportement me répugne de plus en plus.

                    L'avantage quand son comportement répugne, c'est qu'on peut changer.
                    Car bon, le premier à mentir en mettant cet exemple comme "horrible" alors que si on regarde ça a certes merdé mais pas tant que ça (peu de pertes), c'est quand même toi, et ce sans essayer de comprendre les réponses.

                    Et surtout, on note que alenvers est Dieu, parfait et n'ayant jamais fait la moindre erreur. ou alors c'est un autre mensonge (à soit même).

                    Bref, Ce qui te répugnes est plus proche de toi que tu ne l'imagines (non, ce n'est pas ce site qui te répugnes en réalité, regarde plus près de toi).

    • [^] # Re: Tard

      Posté par  (site web personnel) . Évalué à 3.

      Salut Étienne,

      On utilise Gitlab et Gitlab CI au boulot, c'est bien pratique.

      On l'utilise pour tester unitairement, avec Selenium, déployer continuellement les env de staging et la doc, et automatiquement l'env de prod le tout dans docker.

      Même notre intégration Salesforce y passe ( https://hub.docker.com/r/simkim/salesforcedx-gitlab-ci/ )

      On peut échanger plus en détail à un déjeuner si tu veux.

    • [^] # Re: Tard

      Posté par  . Évalué à 3. Dernière modification le 19 juillet 2017 à 09:46.

      Avez-vous touché à la CI de GitLab ? Elle me semble supérieure à tout ce que j'ai testé pour ma part : Bitten, Jenkins/Hudson, Travis, CircleCI et Buildbot.

      Je ne connais que jenkins, mais je serais pas aussi tranché :)

      gitlab-ci est très sympa car il arrive directement avec le support de docker et qu'il est facilement possible de créer un runner sur n'importe quel machine (et pour son intégration à gilab évidement).

      Par contre pour un certain nombre de choses c'est bien plus root que jenkins (si tu veux pouvoir chainer des actions, utiliser ansible, avoir un rapport des tests (en tout cas avec java),…).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Gitlab → Gogs

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Le projet Tiny Tiny RSS utilisait Gitlab, mais il vient de passer à Gogs.
    Les raisons en sont données sur le forum interne.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # Version communautaire limité

    Posté par  . Évalué à 8. Dernière modification le 18 juillet 2017 à 09:54.

    La version communautaire est pour ma part limité, il y a une fonctionnalité qui n'existe que dans la version commerciale et qui est pour moi déterminante qui est celle de la stratégie de merge sur un pull request. Avec la version communautaire seulement le merge request est permis, adieu les possibilités de rebase/squash+cherry-pick qui permettent d'avoir un historique linéaire.

    Coté CI de gitlab, c'est assez simple à faire marcher par contre c'est beaucoup trop lié à GIT donc dès que tu veux faire des choses qui sont périodique avec tu te retrouve à bidouiller de faux événements git via cron, la dessus Jenkins est bien plus puissant. Pareille pour ce qui est tableau de reporting (avoir de joli graphique qui parle au chef de projet sur le nombre de tests qui passe etc…), coté gitlab on est très très limité.

    • [^] # Re: Version communautaire limité

      Posté par  . Évalué à 0.

      Avec la version communautaire seulement le merge request est permis, adieu les possibilités de rebase/squash+cherry-pick qui permettent d'avoir un historique linéaire.

      Et quel est intérêt d'avoir un historique linéaire ? Rien ne t'empêche de rebase avant de merger

      • [^] # Re: Version communautaire limité

        Posté par  (site web personnel) . Évalué à 6.

        Et quel est intérêt d'avoir un historique linéaire ?

        Bah c'est plus lisible et clair.
        Les parties non linéaires de l'historique doivent être normalement utilisées pour des changements fondamentaux qui ont été réalisé dans une branche séparée de longue durée. Par exemple pour inclure une grosse fonctionnalité, ou pour porter vers une nouvelle version (conversion Python 2 vers 3 typiquement).

        Pour des travaux plus élémentaires et simples, ça ajoute de la confusion pour aucun gain.

      • [^] # Re: Version communautaire limité

        Posté par  . Évalué à 6.

        Rien n’empeche de rebaser + squasher avant de merger, certes, mais c’est vachement moins relou si une machine le fait.
        Le reviewer a pas besoin de demander à l’auteur de rebase + merge.

        Sans compter que si t’as une activité décente sur le projet, voilà ce qu’il se passe:
        - plusieurs PR creees, toutes rebasees proprement sur master,
        - review d’une, et merge,
        - review d’une autre et « cool, c’est bon, mais heu, tu peux rebaser steu plait? » le mec est sur un autre fuseau horaire, alors on attendra demain
        - review de la suivante, et heu, tu peux rebaser steuplait?
        - la deuxième a été rebasee et mergee entre temps, et paf, la troisième se tape encore un rebase. C’est sans fin.

        l’alternative, c’est des historique de merde ou la moite des commits sont des merges commit, et un enfer pour celui qui fait de l’archéologie pour savoir quel commit a peter la feature x.

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

          Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Version communautaire limité

          Posté par  . Évalué à 1.

          Le problème du rebase c'est que tu peux être amener à devoir corriger des conflits potentiellement obsolètes (car tu appliques commit par commit) alors que le merge tu corriges une et une seule fois maximum.

          • [^] # Re: Version communautaire limité

            Posté par  . Évalué à 5.

            D’où l’intérêt de cette feature. Tu te contentes de merger master dans ta branche, et la forge s’occupe de squasher et rebaser ça dans un joli commit. En tout c’est comme ça que github fonctionne.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Version communautaire limité

      Posté par  . Évalué à 4.

      Les tâches périodiques ont existé et devraient bientôt revenir, c'est réparé: https://gitlab.com/gitlab-org/gitlab-ce/issues/30882 avec ça pas (plus) besoin de cron.

    • [^] # Re: Version communautaire limité

      Posté par  . Évalué à 1.

      Effectivement ça serait très pratique d'avoir cette fonctionnalité dans la version Gitlab-ce, mais d'un autre coté il faut bien que GitLab Inc. gagne sa vie en vendant des versions Enterprise.

    • [^] # Re: Version communautaire limité

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      J'ai lu que si GNOME choisissait finalement Gitlab, ces derniers accepteraient de passer certaines fonctionnalités dont le projet aurait besoin dans la version communautaire.

      • [^] # Re: Version communautaire limité

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Un lien ?

        • [^] # Re: Version communautaire limité

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Me souviens plus si c'était ce message exactement, mais on va dire que ça fait l'affaire ;-)

          « Your concern is about using fast forward merge. Yes, we raised this concern as the top most important for us, and as we mention in the wiki we have good news, GitLab team is willing to strongly consider making fast forward merge to CE if GNOME decides to switch to GitLab. »

          • [^] # Re: Version communautaire limité

            Posté par  (site web personnel) . Évalué à -2.

            C'est moi ou ça ressemble à du chantage? Bon le mot est sans doute mal choisi, mais perso ça me donne une mauvaise impression genre bon si un gros vient ça nous fait de la pub donc négocions du code libre pour que les libristes fassent pression sans plus se poser de questions sur l'intérêt technique.
            je suis conscient qu'il faut payer les devs mais j'avoue avoir un peu de mal avec ces méthodes "open core à débattre suivant x".

            • [^] # Re: Version communautaire limité

              Posté par  (Mastodon) . Évalué à 2. Dernière modification le 20 juillet 2017 à 14:48.

              Si ça leur permet probablement une rentrée d'argent plus sûre qu'une boite qui ne vend que du service (et sera donc en concurrence directe avec d'autres sociétés de services qui ne font qu'un minimum voire pas du tout de developpement), ça leur coûte aussi en flexibilité. Voir par exemple leur explication sur ce qu'ils doivent vérifier quand ils veulent utiliser des librairies/gem externes pour ne pas mettre du code gpl/agpl dans leur version libre ou enterprise.

              Après c'est vrai que je ne suis pas hyper fan de ce genre de méthode même s'ils sont loin d'être les derniers et que c'est un peu la mode actuelle. Cependant à leur crédit on peut souligner que :
              - leur version libre est très utilisable comparée à la version community/libre de plein d'autres produits qui sont du coup juste des faire-valoirs.
              - ils portent régulièrement des fonctionnalités de la version enterprise vers la version community. Ce n'est pas une version au point mort.

              Après je préfèrerais qu'ils ne fassent que du libre quite à ne fournir du support/compilation/packaging qu'à ceux qui payent.

  • # Emacs y pense !

    Posté par  . Évalué à 4.

    Emacs aussi va certainement pas forcément totalement passer à Gitlab, mais l'utiliser, notamment pour la CI: http://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00592.html

    Pas sûr du tout qu'ils abandonnent le fonctionnement par mail, ça a quelques avantages (pour les gros projets seulement ?) https://lwn.net/Articles/702177/

    +: https://www.reddit.com/r/emacs/comments/6nlsjz/emacs_dev_gnu_savannah_vs_gitlab/

  • # et Tuleap ?

    Posté par  . Évalué à 4.

    On a une équipe qui est venue parler de Tuleap ici, mais il n'est évalué dans aucun des cas :/ C'est juste un manque de notoriété ?

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 6.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # Forges

    Posté par  . Évalué à 5.

    GOGS, Gitea, Pagure, Phabricator et GitLab

    Je suis surpris de voir que redmine n'est pas de la partie. C'est l'une des meilleures forges que j'ai pus voir. Notamment le gestionnaire de ticket des forges plus récentes que j'ai eu l'occasion d'essayer est généralement très minimaliste, ce qui est gênant pour pour moi.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Forges

      Posté par  . Évalué à 2.

      Et si vous cherchez un truc sans dépendances pénibles, pas trop gourmand et ultra facile à installer sur n'importe quoi, vous avez aussi Gitbucket. C'est le point faible de tous les autres que j'ai eu l'occasion de tester, le côté overkill et complexité à administrer quand on a moins de 10 utilisateurs.
      Ca n'est évidemment pas le même cas d'utilisation que Gitlab, outil excellent, avec plein de fonctionnalités intégrées (et débilement gourmand sur une petite install).

  • # Le problème de fond

    Posté par  (site web personnel) . Évalué à 4.

    Le jour ou j'ai entendu parler pour la première fois de GIT comme étant "distribué", je me suis dis "chouette, plus besoin de forge (sourceforge à l'époque)".

    Et puis quand j'ai vu ce que "distribué" signifiait, j'ai été me recoucher.

    Le problème de fond, c'est que l'on ne peut pas faire de PR/MR à partir de GIT, car Mr Torvalds préférait l'email.

    Maintenant on en est à devoir rajouter des binaires clients propre à chaque platerform pour pouvoir faire des MR/PR en ligne de commande. Autrement on est condamné à utiliser une interface web.

    • [^] # Re: Le problème de fond

      Posté par  (site web personnel) . Évalué à 7.

      je me suis dit "chouette, plus besoin de forge (sourceforge à l’époque)".

      Certes, il y a déjà eu quelques tentatives de revues de codes distribuées, telle que git-appraise, mais ça n’a pas décollé pour l’instant.

      Ensuite, ces forges logicielles proposent souvent un paquet de fonctionnalités ensemble, ce qui les rend assez intéressantes finalement (gestion de bogues, compilation automatique + outils d’analyse de code, point d’entrée du projet (README), etc.)

    • [^] # Re: Le problème de fond

      Posté par  . Évalué à 8.

      On pourrait arreter SVP de mettre des sigles partout sans les expliquer ? C'est quoi PM/MR?

      • [^] # Re: Le problème de fond

        Posté par  . Évalué à 2.

        Pull Request/Merge Request

      • [^] # Re: Le problème de fond

        Posté par  (Mastodon) . Évalué à 5.

        D'après le contexte je dirais qu'il parle de Pull Request / Merge Request mais c'est vrai que c'est insupportable cette manie française d'utiliser des acronymes à l'excès.

        • [^] # Re: Le problème de fond

          Posté par  (site web personnel) . Évalué à 2.

          C'est typiquement français ?

          • [^] # Re: Le problème de fond

            Posté par  (Mastodon) . Évalué à 4. Dernière modification le 19 juillet 2017 à 11:54.

            Pour vivre à l'étranger ce n'est pas une exclusivité française d'utiliser des acronymes, mais d'en abuser à ce point et de les mentionner systématiquement sans avoir au préalable énoncé la définition à son interlocuteur au moins une fois oui.

          • [^] # Re: Le problème de fond

            Posté par  (Mastodon) . Évalué à 6.

            Pour illustrer (à part les fameuses RTT j'ai inventé les acronymes parce que je n'en connais pas les équivalents):

            Un français te dira qu'il a du prendre un RTT pour aller au bureau GRUPNIC de la SCRUD locale pour aller chercher le SPLONC afin que sa demande de RSLTTLG soit prise en compte par la AADRMUSV.

            Un suisse te dira qu'il a pris congé pour aller au contrôle des habitants de sa ville pour récupérer une attestation de domicile nécessaire à sa demande de subside d'assurance maladie.

            Quand je discute avec mes proches qui sont restés en France le décalage me parait en tout cas énorme et je dois les reprendre souvent pour comprendre de quoi on parle. Mais je pense qu'un Français qui est plus au courant des ceux-ci n'y fait pas forcément attention. C'est un peu lié au fait que les gouvernements français n'ont eu de cesse de créer de nouvelles institutions/organismes/procédures aux noms à rallonge et toujours plus pompeux.

      • [^] # Re: Le problème de fond

        Posté par  . Évalué à 10.

        Mettre des sigles incompréhensible et inutile permet de montrer sa supériorité: il y a ceux qui savent et les autres, forcément moins bons, un peu à la traîne.

        C'est exactement pareil avec l'anglais : mettre un mot anglais permet de bien montrer à ceux qui ne comprennent pas combien ils sont bouseux. Exemple simple: « On va mettre en place une task force pour manager le projet, qui sera lancé par un workshop. ».

        À mon avis on est pas près de voir disparaître ces sigles, qui font exactement ce qu'ils sont sensés faire : rendre supérieur des gens qui n'y serait très probablement pas.

        • [^] # Re: Le problème de fond

          Posté par  . Évalué à 10.

          On lance pas un projet avec un workshop, on fait un kick-off meeting ^^

        • [^] # Re: Le problème de fond

          Posté par  (Mastodon) . Évalué à 8.

          Mettre des sigles incompréhensible et inutile permet de montrer sa supériorité: il y a ceux qui savent et les autres, forcément moins bons, un peu à la traîne.

          Mettre des sigles et les changer suffisamment fréquemment, c'est aussi un moyen d'embrouiller. On pourrait prendre l'exemple de TAFTA ou TTIP ou PTCI, il porte plein de noms, ça permet de ne plus savoir de quoi on parle et hop, ni vu ni connu je te fais passer ça comme une lettre à la poste. Dans un autre genre, il y a les sigles d'entreprises historiques, en ce moment c'est la mode, ERDF devient ENEDIS, GDF devient ENGIE. À la fin, tu as oublié qu'à la base, c'était des entreprises publiques, et s'il le faut, ça changera encore de nom. Bref, dans tous ces cas, ce n'est pas pour montrer sa supériorité, c'est qu'on connaît beaucoup moins bien un truc qui n'a pas de nom mais juste un sigle.

        • [^] # Re: Le problème de fond

          Posté par  . Évalué à 3.

          Après, il y a certaines administrations qui se sont spécialisés dans les acronymes. L'armée française est très forte pour ça. Un nouveau système, une nouvelle organisation, hop, un acronyme. Je pense que plutôt que s'embêter à trouver un nom français, il est plus simple, et surtout plus court, de trouver un acronyme. Il doit aussi y avoir un phénomène culturel, où le langage permet de former un certain esprit de corps, ce qui est un phénomène assez courant, même dans l’informatique.

      • [^] # Re: Le problème de fond

        Posté par  . Évalué à -1.

        Le problème n'est pas tant d'utiliser des sigles, ce qui est inévitable, mais c'est surtout de ne pas pouvoir enrichir facilement un sigle avec un lien ou une signification, ce qui est je trouve une des plus grandes lacunes du web actuel (et par ricochet de linux.fr). Cette critique ne se réduit d'ailleurs pas uniquement aux sigles, mais également à toutes les erreurs (de frappe, d'orthographe, de syntaxe, de grammaire, de conjugaison…), dont les 3 premiers commentaires de ce journal sont la parfaite illustration (et qui viennent ainsi pourrir le flux des commentaires)…

        En utilisant un système de blog basé sur Git, ça aurait au moins le mérite de rendre la chose possible (à défaut d'être ergonomiquement à la portée de l'utilisatieur lambda).

        Si vous avez des solutions à ces problèmes, ça m'intéresse.

        • [^] # Re: Le problème de fond

          Posté par  (site web personnel) . Évalué à 3.

          Quel est le rapport avec git ? Sur DLFP tu peux lier un lien à ton acronyme, comme sur un paquet de systèmes de forum/commentaire. C'est un bot qui a écrit ce commentaire en générant du contenu en plaçant git à tout prix ?

    • [^] # Re: Le problème de fond

      Posté par  . Évalué à 2.

      Maintenant que j’ai compris ce que veut dire PR/MR, je ne vois pas le problème.

      Git a été pensé pour que chacun est un dépôt privé et un dépôt public. La façon dont Linus ou autre l’a pensé au départ pour le kernel était ce schéma :

      
 Dépôt officiel       Dépot public
       ^      \       (dev. occ.)
       |       \      /    ^
       |        \    /     |
       |         \  /      |
       |          \/       |
       |          /\       |
       |         /  \      |
       |        /    \     |
       |       /      \    |
       V      V       V    V
   Intégrateur       Dév. moyen
(droit d’écriture)

      dev.occ. = développeur occasionnel.

      Le développeur occasionnel récupère le dépôt et fait ses corrections. Ensuite il pousse sur son dépôt public puis doit effectivement prévenir quelqu’un qu’il a fait le taf. (par mail, bugtracker…) l’intégrateur va récupérer les modifs. Si elles n’ont pas le niveau attendu, elles n’iront jamais sur le dépôt officiel. Si c’est bon, c’est l’intégrateur qui pousse sur le dépôt officiel.

      Cas des forges (attention, si je commets des erreurs, merci de me corriger)

       Dépôt officiel <---->Dépot public
       ^              (dev. occ.)
       |                   ^
       |                   |
       |                   |
       |                   |
       |                   |
       |                   |
       |                   |
       |                   |
       V                   V
   Intégrateur       Dév. moyen
(droit d’écriture)

      Du coup, l’intégrateur doit accepter la modification sur son dépôt public avant de pouvoir l’accepter ?

      En tout cas, les échanges de dépôts ne suivent pas la logique initialement pensée.

      Dites moi si j’ai bien suivi.

      • [^] # Re: Le problème de fond

        Posté par  . Évalué à 1.

        Le développeur occasionnel récupère le dépôt et fait ses corrections. Ensuite il pousse sur son dépôt public puis doit effectivement prévenir quelqu’un qu’il a fait le taf. (par mail, bugtracker…) l’intégrateur va récupérer les modifs. Si elles n’ont pas le niveau attendu, elles n’iront jamais sur le dépôt officiel. Si c’est bon, c’est l’intégrateur qui pousse sur le dépôt officiel.

        Il n'y a pas besoin de mail. Lorsque le dev occ a poussé ses modifications sur une branche sur son dépôt (dépot public sur ton schema) il crée une MR/PR via l'interface web, une PR/MR est simplement une demande d'intégration d'une branche d'un dépôt forké sur une branche (en général master) du dépot officiel. L'intégrateur n'a plus qu'à lire le diff et peut accepter en un clic (ou faire des commentaires sur une ou des parties du code si quelque chose ne lui plait pas). Il y a un espace de discussion sur chaque PR/MR

      • [^] # Re: Le problème de fond

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 19 juillet 2017 à 15:59.

        Du coup, l’intégrateur doit accepter la modification sur son dépôt public avant de pouvoir l’accepter ?

        Je suis désolé, j'ai rien compris à tes flèches (pourquoi l'historique du dépôt du dev occasionnel va vers le dev moyen ?), mais si ça peut répondre à ta question, sur Gitlab tu peux ouvrir une MR (c'est bon ça a été défini plus haut maintenant :-P) depuis une branche donnée de ton dépôt perso (typiquement un clone de l'officiel) vers une autre branche d'un autre dépôt (typiquement l'officiel), ce qui correspondrait à une contribution d'un inconnu qui passe par là, ou directement une MR depuis une branche d'un dépôt vers une autre branche du même dépôt (typiquement une contribution de quelqu'un de l'équipe, qui a accès au dépôt et a pu créer sa topic branch, mais pas le droit de push sur master sans review comme un goret non plus).

        Il me semble bien qu'il y a les mêmes possibilités avec les PR sur github mais je l'utilise moins.

        • [^] # Re: Le problème de fond

          Posté par  . Évalué à 2.

          Alors, mon schéma n’était pas assez clair. C’est un tableau à double entrée : en colonne tu as les dépôts des différents dév. et en ligne 0 les dépôts publics en ligne 1 (en bas) les dépôts privé (généralement ton espace de travail).

          Le dév moyen est un développeur occasionnel sur le projet…

    • [^] # Re: Le problème de fond

      Posté par  . Évalué à 7.

      Ce n'est pas le rôle de git de gérer les pull requests, tout comme montrer les commits sur un site web n'est pas non plus son travail.
      Une pull request, c'est un message servant à prévenir qu'il faut valider un ensemble de commits pour l'intégrer à une branche de travail. Donc c'est plutôt un outil de messagerie qu'il faut utiliser. Les modifs attachées au message peuvent être hébergées sur un autre repo git, ou être fournies dans le message lui même. Ca n'a aucune importance, il n'y a même pas de dépendances à une techno particulière, que ce soit un VCS (système de contrôle de version) ou à une méthode d'envoi du message (forum, github, e-mail, message IRC, etc…). Pour des raisons de traçabilité et de simplicité, Linux utilise des emails pour gérer ça, mais ça n'a pas vraiment de couplage avec git.

  • # GitLab 9.4

    Posté par  . Évalué à 1.

    La 9.4 est sortie : https://about.gitlab.com/2017/07/22/gitlab-9-4-released/

  • # Clearcase

    Posté par  . Évalué à 1.

    Dommage que GNOME n'ai pas pensé à migrer vers Clearcase/UCM plutôt ….

    Je sors -------> [ ]

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.