Journal Fermeture progressive de Google Code

Posté par  (site web personnel) . Licence CC By‑SA.
22
13
mar.
2015

Google ferme (progressivement) Google Code : Bidding farewell to Google Code. D'ailleurs, Gitorious ferme également (progressivement) suite à l'acquisition de Gitorious par GitLab : GitLab acquires Gitorious to bolster its on premises code collaboration platform.

Google Code est un site pour héberger des projets libres avec code source (git, mercurial), wiki et suivi des tickets, comme Github, Bitbucket, Sourceforge, Gna, etc. Le site a été lancé en 2006 par Google, et va progressivement fermer. J'en comprends que le site n'était plus assez populaire (rentable?) pour Google. Gitorious ne supporte que Git.

En 2011, c'était BerliOS qui fermait : https://en.wikipedia.org/wiki/BerliOS

Quelques hébergeurs de projets dont le code source du site est libre :

Quelques hébergeurs de projets dont le code source du site est fermé :

(Je n'ai pas pris le temps de dresser une liste exhaustive ni détailler les services ou encore vérifier précisément les SCM supportés, je vous laisse creuser un peu.)

Github & cie sont de plus en plus utilisés par des sociétés pour héberger leur code pour des questions pratiques. C'est plus simple à utiliser que d'administrer ça en interne. La plupart du temps, le service est payant pour avoir un ou plusieurs projets privés. On peut également choisir d'avoir sa forge privée (gratuitement ou en payant selon le site choisi), choix plus sécurisant pour protéger son code source propriétaire des redoutés "chinois du FBI".

  • # Et SourceSup

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

    SourceSup, la forge enseignement supérieur et recherche gérée par le GIP Renater.

    Même si l'accès n'es pas du même genre que ceux cités, certains projets issus de ces milieux y sont hébergés.

    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: Et SourceSup

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

      Mon dieu c'est presque aussi horrible que la forge de l'Adullact. Quoique sur l'Adullact on arrive encore à naviguer dans les sources en insistant. Gitlab n'a pas de soucis à se faire.

      • [^] # Re: Et SourceSup

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

        Je crois que, vu la news commentée, la question est: est-ce que les utilisateurs de gitlab / github ont des soucis à se faire sur la possibilité d'une fermeture de ces services ?

        Bref, quelle est la pérennité des sources mises en ligne sur ces sites ?

        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

        • [^] # Re: Et SourceSup

          Posté par  . Évalué à 3.

          Gitlab peut parfaitement tourner en interne.

          Github aussi d’ailleurs, mais faut payer pour ça.

          • [^] # Re: Et SourceSup

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

            L'idée est que ca ne tourne pas "en interne" avec le matériel et les bons hommes pour le gérer, mais dans une structure publique gérée par Renater.

            Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

            • [^] # Re: Et SourceSup

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

              Et mon idée (visiblement mal exprimée parce que si elle avait été claire je pense que j'aurais pris des moinssages) c'est que plutôt que développer une horreur comme ce truc, Renater (ou les collectivités locales dans le cas de l'Adullact) feraient mieux de consacrer une partie du budget qu'ils ont englouti dans le développement de leurs Mygale dans l'installation d'un gitlab, une autre dans les éventuels dév. spécifiques dont ils auraient besoin, et le reste ça serait des économies d'argent public. Les chercheurs / fonctionnaires auraient mieux pour moins cher.

              • [^] # Re: Et SourceSup

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

                Sauf que là tu parts comme si ça venais de s'installer.

                Eux sont partis il y a quelques années déjà, avec le support de différences SCM, a priori en se basant sur FusionForge (fork de GForge/SourceForge). Ça évolue à sa vitesse, et ça fournit des services.

                À la vitesse où les services gitX/googleY évoluent, se font racheter, disparaissent… j'aimerais voir dans 10 ans ce qu'il restera.

                Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

                • [^] # Re: Et SourceSup

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

                  À la vitesse où les services gitX/googleY évoluent, se font racheter, disparaissent… j'aimerais voir dans 10 ans ce qu'il restera.

                  C'est quoi la plus grande pérennité entre :

                  • se baser sur un gros projet existant (et vivant) et n'avoir qu'à faire les devs spécifiques en interne (et même pas forcément les maintenir si on les fait accepter en amont)
                  • partir from scratch en mode NIH des familles (ou depuis le cadavre d'un projet qui n'intéresse plus personne) et devoir tout faire en interne

                  ? Je sais pas mais j'ai l'impression qu'il y a un cas où en plus des ressources internes, il y a une communauté (parfois même une boite qui fait des ronds et peut donc payer des gars pour bosser dessus) avec la pérennité qu'elle apporte.

                  • [^] # Re: Et SourceSup

                    Posté par  . Évalué à 4. Dernière modification le 18 mars 2015 à 11:23.

                    La migration ça à un coût. Élevé. Si une infra existe depuis, disons, rien que 5 ans en utilisant une techno, la faire évoluer en changeans de techno, c'est quelque chose d'assez glissant quand même.

                    Tu te frottes au risque (très fort) de galères lors de la migration, à la résistance au changement. Et ce n'est pas spécialement simple à gérer.
                    Maintenant, on ne parle pas d'un truc mis en place dans les années 2010 ici, mais, manifestement, d'une organisation qui date de 1993: une époque ou ni github, ni google, ni git n'existaient.
                    Pour ne rien aider, on parle d'une institution publique.

                    Et puis franchement, le soft derrière sourceforge, qui est aussi derrière renater manifestement, on ne peut dire qu'une chose: il à fait ses preuves, sur la durée. Il est d'ailleurs encore vivant, sisi, parce que savanne, c'en est un fork. Maintenant, reste à savoir si les équipes de maintenance de renater et celles de gnu échangent du code.

                    Allez, juste pour en finir avec la notion de différence en terme de temps d'existence. Github à été créé en 2008. La boîte derrière sourceforge, à été rachetée en 2007. Mais existait déjà bien avant: dommage, je n'arrive pas à trouver la date à laquelle tout ça à été créé.

                  • [^] # Re: Et SourceSup

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

                    Ils ne sont pas partis d'un cadavre, ils ont développé tout ça y'a 10 ans quand Sourceforge, c'était cool, et que gitlab, ça n'existait pas. Et maintenant ça tourne, alors pourquoi migrer?

    • [^] # Re: Et SourceSup

      Posté par  . Évalué à 3.

      En quoi est-elle plus pérenne qu'autre chose ?

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

      • [^] # Re: Et SourceSup

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

        Disons qu'il y a quelques structures publiques derrière le Groupement d'Intérêt Public Renater:

        • CNRS (Centre National de la Recherche Scientifique),
        • CPU (Conférence des Présidents d'Université),
        • CEA (Commissariat à l'Énergie Atomique),
        • INRIA (Institut National de Recherche en Informatique et en Automatique),
        • CNES (Centre National d'Études Spatiales),
        • INRA (Institut National de la Recherche Agronomique),
        • INSERM (Institut National de la Santé et de la Recherche Médicale),
        • ONERA (Office National d'Études et de Recherches Spaciales),
        • CIRAD (Centre de coopération Internationale en Recherche Agronomique pour le Développement),
        • IRSTEA (Institut national de Recherche en Sciences et Technologies pour l'Environnement et l'Agriculture),
        • IRD (Institut de Recherche pour le Développement),
        • BRGM (Bureau de Recherches Géologiques et Minières),
        • MESR (Ministère de l'Enseignement Supérieur et de la Recherche)


        Au niveau de Renater, les membres peuvent tout à fait décider de stopper ce groupement, mais ils auront alors à fournir d'une autre façon les services correspondants et leur gestion (dont les interconnexions IP rapides entre ces établissement — SourceSup n'est qu'un des services de Renater).

        Et au niveau de SourceSup, au moment où les autorités qui chapeautent les organistes au niveau sécurité essaient d'éviter que les données soient mises sur des hébergements étrangers… ça serait aberrant de le stopper.

        Mais rien n'est éternel je te l'accordes.

        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

        • [^] # Re: Et SourceSup

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

          Inquiétant que dans ces treize institutions réunies il n'y ait aucun ergonome ni aucun designer.


          Ni aucun CTO capable de se rendre compte qu'il existe déjà mieux en Libre, voire aucun développeur web tout simplement.

          • [^] # Re: Et SourceSup

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

            Inquiétant que dans ces treize institutions réunies il n'y ait aucun ergonome ni aucun designer.

            Si, occupés à faire de la recherche, pas du développement pour des outils.

            Ni aucun CTO capable de se rendre compte qu'il existe déjà mieux en Libre, voire aucun développeur web tout simplement.

            Si, payés pour des projets de recherche, pas de développement de tels outils.

            Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

            • [^] # Re: Et SourceSup

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

              Donc tu confirmes qu'ils ont lancé des mecs (et encore, on se demande quoi, si y a ni dév ni ergonome ni CTO) dans le dév d'une forge sans les encadrer et sans avoir une équipe cohérente.

              Remarque ça explique beaucoup de choses.

              • [^] # Re: Et SourceSup

                Posté par  . Évalué à 4.

                Et peut-être qu'a l'époque ou ça à été lancé, il y avait des contraintes différentes: bande passante inférieure, machines moins puissantes, par exemple.

                Parce que, désolé hein, mais github, c'est une catastrophe si t'as pas un PC musclé. Alors que je me souviens avoir utilisé SF.net il y à plus de 10 ans sans problème de perf. Ma mémoire me trompe peut-être (très probable: après tout, au bout de 10 ans…), mais j'ai bien l'impression que si, ok, il y avait moins de blinbling, c'était plus rapide. D'ailleurs, aller sur gnu.savanah.org ou sourceforge est toujours plus rapide à l'heure actuelle que sur github.

  • # Déjà posté deux journaux plus bas

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

    • [^] # Re: Déjà posté deux journaux plus bas

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

      Journal Gugöl Khod bronsonisé

      Euh, si ça parle de la même chose, il faudrait utiliser un titre plus clair :-p

      • [^] # Re: Déjà posté deux journaux plus bas

        Posté par  . Évalué à 1.

        moi quand je poste un journal, je regarde la liste des journaux précédents pour voir s'il n'y a rien de similaire. Le titre du mien n'est effectivement pas très explicite (c'était censé faire sourire), mais la première ligne l'est et elle est bien visible sur la page des journaux.

        À ta décharge, son journal contient plus d'informations intéressantes que dans le mien.

        « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

      • [^] # Re: Déjà posté deux journaux plus bas

        Posté par  . Évalué à 0.

        Bah oui quoi, ça veut dire quoi "bronsonisé" ?

  • # Bientôt GMail

    Posté par  . Évalué à 0.

    Avec les récentes affaires et les préoccupation sur la vie privée, des solutions d'auto-hébergement de plus en plus simples commencent à avoir le vent en poupe (Cozycloud / OwnCloud / etc…)

    Il y a par exemple de boîtiers NAS (QNap/Synology) où l'on peut configurer son serveur ldap/samba/dovecot/postfix en quelques clics, qui même si ils ne sont pas encore très simples. Certains intègrent Owncloud préconfiguré, par exemple.

    Ajoutez à cela l'arrivée lointaine, mais inéluctable d'IPv6, et la configuration NAT ne sera plus nécessaire. Je sais, on est loin, mais AMHA, ce n'est qu'une question de temps.

    Enfin - malheureusement? - les emails tendent à être de moins en moins utilisés dans le domaine privé, au profit des réseaux sociaux (bidons?). Ce dernier point est discutable, mais malheureusement, de plus en plus de jeunes n'utilisent plus que facebook, pour communiquer avec leur entourage.

    De la même façon que les mainframes IBM / UNIX et ses offress SaaS on été dépassées par des offres moins onéreuses et plus adaptées, les offres "cloud" des géants de l'informatique comme Amazon / Microsoft et Google sont vouées à disparaître, au profit de solutions "internes".

    Vous pouvez ne pas être d'accord, mais pour ma part, je pense que dans quelques décennies, les entreprises auront à nouveau rapatrié leurs emails / documents / assets en interne, en utilisant des solutions matérielles et logicielles intégrées, qui ne demanderont que très peu de maintenance et de technicité.

    • [^] # Re: Bientôt GMail

      Posté par  . Évalué à 3.

      Ajoutez à cela l'arrivée lointaine, mais inéluctable d'IPv6

      Aujourd'hui, Google dit recevoir 6% de ses visites en IPv6, alors que début 2013 c'était 1% :
      http://www.google.fr/ipv6/statistics.html

      IPv6 arrive maintenant, pas dans le futur.

      De la même façon que les mainframes IBM / UNIX et ses offress SaaS on été dépassées par des offres moins onéreuses et plus adaptées,

      Je ne serais pas aussi optimiste : rappatrier les données en interne coûte cher : économiquement je ne pense pas qu'on puisse concurrencer un amazon ou Google. Et puis je suppose que les États et les services vont payer très cher pour empêcher un meilleur contrôle des données par les utilisateurs… concurrencer tout ça sur le plan strictement économique me semble illusoire.

      • [^] # Re: Bientôt GMail

        Posté par  . Évalué à 1.

        Je reste, pour ma part, totalement optimiste, mais sur du long terme, c'est à dire dans quelques dizaine d'années.

        L'arrivée de serveurs basse consommation ARM64 et la baisse des disques durs (SSD ou non) aidant, les entreprises ramèneront, tôt ou tard, leurs données en interne. Plus pour éviter des solutions «vendor lock-in» et de contrôle interne de leurs données que pour des raisons de coût.

        Il ne s'agit aucunement de concurrencer google, puisque la quantité d'informations qu'une entreprise héberge sur une offre cloud est largement négligeable comparée aux quantité de données gérée par ces empires, i.e Google/Amazon/Azure/etc…

        • [^] # Re: Bientôt GMail

          Posté par  . Évalué à 8.

          L'arrivée de serveurs basse consommation ARM64 et la baisse des disques durs (SSD ou non) aidant, les entreprises ramèneront, tôt ou tard, leurs données en interne.

          Ça n'a jamais était le prix du matériel qui freine les entreprises. Le matériel c'est combien ? Disons 2 000 € pour 2 machines et un routeur à 500 €, le tout renouvelé tous les 2 ans. Une petite centaine d'euros par mois ce n'est pas grand chose comparé aux prix d'un admin pour s'occuper de ça, il n'y a pas photo.

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

    • [^] # Re: Bientôt GMail

      Posté par  . Évalué à 3.

      Il y a par exemple de boîtiers NAS (QNap/Synology) où l'on peut configurer son serveur ldap/samba/dovecot/postfix en quelques clics, qui même si ils ne sont pas encore très simples. Certains intègrent Owncloud préconfiguré, par exemple.

      De plus, la future version de Synology promet encore plus de soft grâce à l'ajout du support de docker…

      • [^] # Re: Bientôt GMail

        Posté par  . Évalué à 3.

        Docker ne sera pas pour tout le monde chez synology.
        Ils donnent une liste des modeles eligibles, et c'est assez court.
        Moi qui pensait pouvoir jouer un peu avec docker simplement sans y esperer des etincelles avec mon 414, et ba non.

      • [^] # Re: Bientôt GMail

        Posté par  (site web personnel) . Évalué à 0. Dernière modification le 17 mars 2015 à 01:20.

        J'espère juste être assez loin de toi, ou tout autre expert en hébergement mondialement reconnu par DLFP, et du patron de PME à qui vous avez promis la lune avec un ownCloud posé tel une pêche de lendemain de fête dans un docker sur un Synology en raid1 avec deux DD noname sans réplication à distance, le jour où il cramera pour une quelconque des 10 000 raisons possibles. Pour pas me faire crever un oeil par une des dents qui voleront.

        • [^] # Re: Bientôt GMail

          Posté par  . Évalué à 3.

          Il faut bien garder en tête que je parie sur du long terme, pas maintenant.

          Mais regardons déjà maintenant. Ces boîtier NAS proposent déjà la réplication à distance sur un autre boîtier NAS et la sauvegarde incrémentale sur les principaux hébergeurs "cloud" genre Amazon/Rackspace File/etc.

          Avec la première fonction, sans connaissances techniques, tu peux déjà avoir deux offices qui partagent de manière transparente les même données. C'est un premier point pour un plan de reprise d'activité (DR) si une des offices brûle, comme tu dis. Comparé au prix du To chez un hébergeur cloud, ça se défend, surtout si tu prends en compte qu'un réseau de base en 10G reste plus rapide qu'une connexion ADSL.

          Concernant l'intégration, l'authentification s'intègre de manière transparente avec un serveur AD ou Samba/OpenLDAP.

          Ensuite, il n'y a pas que du RAID2. Tu peux trouver un boîtier NAS RAID6 avec 8 disques durs / 12To pour 1000€ HT, soit 2000€ pour deux boîtier répliques à distance utilisant rsync. Tu as aussi des applis tablettes natives avec accès aux fichiers office, par exemple, avec synchronisation "off-line". Alors oui, pour une PME, ça peut d'ores et déjà être intéressant.

          Lorsque Microsoft NT faisait commençait à faire de la concurrence à UNIX pour les serveurs d'entreprise, IBM se marrait…Aujourd'hui, combien de sociétés utilisent AD/Exchange pour leur infrastructure?

  • # Sourceforge

    Posté par  . Évalué à 5.

    Quelques hébergeurs de projets dont le code source du site est fermé :

    c'est marrant tu parles de sourceforge un peu plus haut et tu oublies d'en parler dans ta liste.

    Sourceforge a beau être pourri au niveau interface, au moins il dure.

    • [^] # Re: Sourceforge

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

      Ca existe encore Sourceforge ? Je croyais que c'était devenu un site qui rajoute des malwares dans les exécutables Windows :-)

      • [^] # Re: Sourceforge

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

        La dernière fois que j'ai utilisé SourceForge, au bout d'un mois notre dépôt svn a été bloqué, impossible de pusher (terme git, je sais) quoi que ce soit. On s'est barrés :)

        Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # phabricator ?

    Posté par  . Évalué à 9. Dernière modification le 13 mars 2015 à 13:47.

    Une forge open sources que l'on peut installer chez sois :
    http://phabricator.org
    C'est Facebook qui a commencé le projet
    Le seul reproche : ce n'est pas en français
    On l'utilise à la boîte.

    • [^] # Re: phabricator ?

      Posté par  . Évalué à 4.

      Phabricator est utilisé par le projet enlightnement.

    • [^] # Re: phabricator ?

      Posté par  . Évalué à 2.

      Autre alternative intéressante en Java qui permet en plus d'y accéder en CLI:
      http://gitblit.com/

      Un simple WAR à déployer

      • [^] # Re: phabricator ?

        Posté par  . Évalué à 3.

        Sur le principe du "simple WAR à deployer", y'a aussi GitBucket écrit en Scala.

        ça a l'air assez complet mais je ne peux comparer en terme de fonctionnalités et de qualité. Par contre, visuellement, ça ressemble plus à ce que fait GitHub et GitLab (et de ce côté là, GitBlit pêche un peu…)

        • [^] # Simple à déployer

          Posté par  . Évalué à 3.

          Sur ce sujet, il me semble vital de citer fossil.
          Juste un binaire à installer, empaqueté par au moins une grande distribution, au pire dispo sur le site officiel pour OpenBSD, Mac OS, Linux 3.X ou pour tout ceux assez motivés pour compiler.

          Point négatif: c'est un VCS à lui tout seul, donc pas d'intégration de git ou mercurial ou svn ou whatever. D'un autre côté, pas mal de forges se reposent uniquement sur Git…

          Point positif: simple à mettre en place, dépôts de source sous forme d'une base SQLite (bon, ok, ça, on peut ne pas être convaincu… sauf qu'en fait, j'ai plus confiance dans une base SQL pour gérer en cas de problème, que dans le filesystem. Du coup, je me demande si mes récentes emmerdes avec un dépôt git fusillé n'auraient pas été évitées avec fossil…).

          Après, c'est fait pour de petits projets, vu qu'on peut pas gérer, à ma connaissance, de lien entre divers projets, contrairement à une solution style git (git extern) + redmine (sous-projets).

  • # Hécatombe

    Posté par  . Évalué à 8. Dernière modification le 13 mars 2015 à 14:00.

    C'est vraiment une hécatombe en ce moment et les projets libres ont pas mal de souci à se faire pour leur hébergement.

    On en a peu parlé ici, mais un autre épisode de ce genre est intervenu dans la communauté Java avec l'annonce par Pivotal de lâcher le sponsoring (et les core devs) de Groovy, cumulée l'annonce de la fermeture de codehaus, une autre forge qui hébergeait ce projet.

    S'est engagé une course pour ce projet afin de retrouver un sponsor. 3 fondations se sont proposées et Apache sera l'heureux élu pour accueillir le projet dans ce que l'on pourrait appeler un "havre".
    http://www.infoq.com/news/2015/03/groovy-moving-to-apache

    Ceci interroge à nouveau sur cette absence cruelle d'offre d'hébergement libre qui ne soit pas soumise aux aléas mercantiles.
    Il semble qu'être maître de son code ne suffise pas (on s'en doutait, mais tout le monde ferme les yeux face au confort apporté par GitHub), alors:

    • Ces fondations devraient-elles lancer des initiatives concurrentes qui se basent sur le don ?
    • Faut-il redonner une seconde chance aux gestionnaires de tickets distribués via une surcouche à Git ou aux outils qui couvrent ces besoins, type fossil, veracity(http://veracity-scm.com/). Quid de tout le reste de la chaîne de production (intégration continue, déploiement, …)
    • Faut-il reprendre gitorious et le faire revivre en tant que projet et en tant que fondation ?

    Des idées ?

    • [^] # Re: Hécatombe

      Posté par  . Évalué à 2.

      À mon avis ça n'a pas grand chose à voir avec le libre.

      Si tu es dépends d'un service externe, tu es moins résilient, c'est sûr. Mais c'est le problème de la sous-traitance bien plus que d'un problème « logiciel libre ». Et le jour où tu mets ton cœur de métier en sous-traitance, tu gagnes peut-être des sous mais lorsqu'il se casse la figure, ça fait très mal.

      Côté libre, il est toujours possible d'installer son truc sur sa machine… En ce moment, ça n'est pas vraiment difficile de trouver un hébergement VPS ou autre digne de ce nom pour n'importe quel projet libre…

      • [^] # Re: Hécatombe

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

        En ce moment, ça n'est pas vraiment difficile de trouver un hébergement VPS ou autre digne de ce nom pour n'importe quel projet libre…

        Mais c'est plus dur de trouver l'admin qui va avec.
        Et c'est bien ce que proposent les forges que les gens veulent utiliser.
        Pour comparer, faudrait que tu proposes un VPS + l'admin qui va avec (et qui va tout te mettre en place pour pas cher, bon courage).

        • [^] # Re: Hécatombe

          Posté par  . Évalué à 2.

          Tout à fait, et là on revient aux questions économiques : qui est prêt à payer pour ce service ? Visiblement pour Google Code pas grand monde malheureusement.

  • # Framasoft va lancer son instance de Gitlab

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

    On a déjà un gitlab qui tourne depuis un certain temps mais nous n'avons jamais eu le temps de l'ouvrir proprement à tout le monde. Pour l'instant, tout nouvel arrivant a droit à 3 dépôts mais on va augmenter ce nombre d'ici ce soir (le temps qu'on se mette d'accord sur le nombre, sans doute entre 30 et 50).
    Pourquoi limiter le nombre de dépôts ? Bah tout simplement parce qu'on n'a pas les épaules pour accueillir trop de gens avec trop de projets. Notre but est toujours, avec nos services, de montrer qu'on peut utiliser des trucs libres à la place de trucs proprios et de permettre de tester avant — on l'espère — d'installer soi-même le service libre. Et notre but n'a jamais été de remplacer Google et consorts :-)

    La récupération en masse des projets github ne fonctionne pas, mais je me demande si c'est pas à cause de notre authentification LDAP (pour les membres de l'asso). S'il y en a parmi vous qui sont intéressés par le Gitlab Framasoft, je veux bien savoir si vous rencontrez le problème aussi. (oui, je pourrais me faire un compte de test, mais… jamais eu le temps ou pensé quand j'ai eu le temps).

    L'URL : https://git.framasoft.org

    L'annonce officielle ne tardera pas à être publiée sur le Framablog

    Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

    • [^] # Re: Framasoft va lancer son instance de Gitlab

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

      Et notre but n'a jamais été de remplacer Google et consorts :-)

      Oui enfin, c'est un peu le cas quand même… (remplacer Google Code)

      • [^] # Re: Framasoft va lancer son instance de Gitlab

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

        Non ! On montre qu'il y a une alternative (Gitlab), on propose de tester, voire de l'utiliser pour de bon si on n'a pas les connaissances, et pour ceux qui ont les connaissances, on propose (proposera pour le cas de gitlab) un tuto d'installation en français sur http://framacloud.org/cultiver-son-jardin/.

        Oui, on est opportunistes car on profite de la fermeture de gg code pour lancer notre gitlab et communiquer dessus, mais on ne cherche pas à remplacer Google ou Github.

        De toutes façons, quand bien même on voudrait le faire on n'a pas les épaules pour et ce n'est pas dans notre philosophie.

        Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

    • [^] # Re: Framasoft va lancer son instance de Gitlab

      Posté par  . Évalué à -3.

      Bah tout simplement parce qu'on n'a pas les épaules pour accueillir trop de gens avec trop de projets.

      Vous pourriez demander conseil à Cécile Duflot. Elle, elle a les épaules.

    • [^] # Re: Framasoft va lancer son instance de Gitlab

      Posté par  . Évalué à 2.

      Il faudra que ce soit plus fiable que Framacalc pour qu'on ait confiance :o(

  • # quelques pépites perdues à jamais

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

    Il y a quelques projets qui ne sont plus actifs, mais marchent bien sur google code ou des bouts de code intéressants…
    Je pense que si personne ne pense à les reprendre c'est un patrimoine applicatif perdu à jamais. Google n'a pas assuré sur ce coup-là.

    En ce qui concerne les alternatives, le problème de beaucoup d'entre elles, c'est qu'elles souffrent d'un manque de notoriété - notoriété pourtant essentielle pour la promotion de son logiciel open source.

    • [^] # Re: quelques pépites perdues à jamais

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

      Je pense que si personne ne pense à les reprendre c'est un patrimoine applicatif perdu à jamais.

      Si personne ne pense à les reprendre (y compris le dev), c'est sans doute parce que ce n'est pas une pépite, justement.
      Google n'est pas un archiviste, pas son rôle de garder.

      En ce qui concerne les alternatives, le problème de beaucoup d'entre elles, c'est qu'elles souffrent d'un manque de notoriété

      GitHub explose Google Code en notoriété. Et GitHub étant aussi libre que Google Code, on ne perd pas de liberté.

      • [^] # Re: quelques pépites perdues à jamais

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

        Je ne parlais pas de github (que j'utilise exclusivement), mais des autres forges beaucoup moins célèbres et citées plus haut.
        Il y a des projets plus maintenus, non parce qu'ils n'intéressent personne, mais parce que dès que tu sors du mainstream, il n'y a plus grand monde pour y contribuer. Et des fois, la vie fait que tu as moins de temps à consacrer à tes projets persos. Je maintiens avoir trouvé des solutions très intéressantes sur google code et regrette leur très probable disparition…

        • [^] # Re: quelques pépites perdues à jamais

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

          Si tu penses qu'il est important de garder tous les projets se trouvant sur Google Code dans une archive publique, tu peux tenter de convaincre archive.org. C'est le genre de trucs qu'ils font.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: quelques pépites perdues à jamais

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 14 mars 2015 à 12:40.

      Google n'a pas assuré sur ce coup-là.

      Ca dépend ce qu'on veut dire par "assuré". Google n'étant pas une association philanthropique ou bien un service public, sa démarche est parfaitement corporate : un service se fait dépasser et n'est plus à la hauteur : ils le ferment et proposent une procédure de migration des projets tout en maintenant les projets consultables pendant un bon moment.
      Donc, dans un sens, si, ils "assurent". Mais juste pas dans ton sens à toi.

    • [^] # Re: quelques pépites perdues à jamais

      Posté par  . Évalué à 4.

      Un projet qui ne bouge plus au point que personne ne prenne une demi heure pour archiver le code ailleurs, je pense que c'est un projet dont tout le monde se fout.

      Pour ce qui est de l'assurance, j'ai des projets dans pas mal de forges et j'ai reçu un mail explicatif clair de Google (j'en avais reçu un du clone libre dont on avait parlé ici-même), mais pas de gitorious.

      Je trouve que c'est dommage parce que c'est une forge que j'aimais bien et je suis un certains nombre de projets dessus (guava, mokito,…).

      Personnellement pour moi c'est l'occasion de faire du ménage dans mes projets.

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

    • [^] # Re: quelques pépites perdues à jamais

      Posté par  . Évalué à 2. Dernière modification le 16 mars 2015 à 12:14.

      e pense que si personne ne pense à les reprendre c'est un patrimoine applicatif perdu à jamais. Google n'a pas assuré sur ce coup-là.

      Hé bien, tu peux le faire j'imagine.

      le problème de beaucoup d'entre elles, c'est qu'elles souffrent d'un manque de notoriété

      Aoutch…. google code est un arriviste et un gagne petit dans ce domaine quand même. Ils ont des projets uniquement parce qu'il s'agit d'un service google, si tu veux mon avis, et que du coup ils bénéficient de l'immense notoriété ainsi que de la base d'utilisateurs enregistrés sur leurs divers services (ça évite de créer un compte sur une Nième forge).
      De toute façon, comparer google code à des forges comme:

      • github
      • bitbucket
      • sourceforge
      • savanah (qui est à la fois le logiciel et le service)

      me semble complètement ridicule. Ceci dit, je dois préciser: je n'ai cité le dernier que pour une seule raison: il s'agit de la seule forge libre fournissant un service libre et gratuit, bien que ce service soit réservé aux projets eux-même libres (comme dans le cas de github d'ailleurs, si on se limite à utiliser la forge gratuitement).

      Je crois qu'on est à plusieurs ordres de grandeur en dessous en général. Je n'ai un doute que pour savanah, je ne sais pas comment savoir le nombre de projets actuellement hébergés dessus. Ah. Je parle de projets, hein, pas d'un simple clone d'un projet mis a disposition des utilisateurs de google code.

      • [^] # Re: quelques pépites perdues à jamais

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

        il s'agit de la seule forge libre fournissant un service libre et gratuit

        o_O il y a https://gna.org tout de même, ainsi que http://tuxfamily.org (pour ce dernier c'est plutôt une plateforme d'hébergement web/download + gestionnaire de code source svn/git/mercurial mais rien n'empêche de s'installer une forge…).

        • [^] # Re: quelques pépites perdues à jamais

          Posté par  . Évalué à 2.

          gna vit encore? J'avais utilisé, mais, pas de MaJ de la forge depuis 2 ans à ce moment, et une forge truffée de problèmes.
          Par contre ouai, j'ai oublié tuxfamily, que je n'ai jamais pratiqué, donc je suis pas trop capable de savoir si c'est juste un dépôt de code source ou une forge complète.

      • [^] # Re: quelques pépites perdues à jamais

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

        il s'agit de la seule forge libre fournissant un service libre et gratuit

        Bah maintenant il y a https://git.framasoft.org :-) Ok, limité à 42 projets, mais j'attends de voir des gens qui les atteignent avant de dire que c'est une vraie limite gênante.

        Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

    • [^] # Re: quelques pépites perdues à jamais

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

      Le site passera en mode "lecture seule", puis dans un deuxième temps en mode "archive", proposant de télécharger une archive de chaque projet pour en extraire les données et les remettre en ligne ailleurs.

      Ils ont également fourni des outils pour faciliter la migration sur d'autres plateformes (sans avoir besoin d'être administrateur du projet du côté google code).

      De plus, avec un hébergement décentralisé (git ou mercurial par exemple), on peut de toutes façons retrouver tout l'historique du repo à partir d'un checkout des sources, donc il y a peu de chance d'avoir des choses définitivement perdues.

      Conclusion: ça se passe beaucoup mieux que lors de la fermeture de berlios ou d'opensvn.

  • # Fonctionnalites manquantes

    Posté par  . Évalué à 1.

    Je viens de migrer mes projets sur github, et je trouve qu'il manque certaines fonctionnalites comme la possibilite d'integrer une video au readme.md ou encore de suivre l'evolution du traffic sur le projet avec google analytics.
    Le fait que l'utilisateur soit accueilli par une page avec le code en tete doit aussi certainement faire fuir des utilisateurs potentiels.

    Y a t-il des alternatives qui proposent une interface propre comme google code avec ces fonctionnalites?

Suivre le flux des commentaires

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