Je ne comprends pas comment cette décision pourrait être bénéfique à GitLab.
Le signal envoyé ici, c'est "n'utilisez plus gitlab.com pour stocker des projets potentiellement peu actifs". Donc, plus aucun projet perso, par exemple, et en fait, plus rien, car un an c'est très court.
De même, éviter de dépendre de projets stockés sur gitlab.com, et qui pourraient être trop peu actifs.
Pourtant il y a d'autres voies possibles:
- archiver ces projets (et non les supprimer)
- augmenter le prix de la solution commerciale
- diminuer l'espace offert gratuitement
Je parie qu'il y aura rétro-pédalage sous peu. Mais le mal est déjà fait… Microsoft se frotte les mains.
Il ne s'agit pas vraiment d'un choix fait librement :
The Register has learned that such projects account for up to a quarter of GitLab's hosting costs, and that the auto-deletion of projects could save the cloudy coding collaboration service up to $1 million a year
Si GitLab était pas en galère financière, je pense pas qu'ils seraient à la chasse aux projets inactifs.
augmenter le prix de la solution commerciale
Ils arrivent déjà pas à la vendre. Côté entreprises t'as soit les droguées de Jira, soit celles qui installent leur propre instance GitLab.
Après c'est vrai qu'un an c'est assez court. Sur un malentendu ou un petit oubli, on va vite devoir dire au revoir à son projet perso. Mais d'un autre côté, personne ne va penser à supprimer lui-même son dépôt de TP d'algorithmique qu'il a fait y'a 7 ans.
Je me demande tout de même quel serait le gain s'ils passaient simplement à un archivage. Normalement cela divise le coût par 10 (ils utilisent le Google Cloud), ce n'est pas négligeable…
Ça a fait grincer des dents mes collègues qui bossent sur libvirt, car les nouvelles conditions semblent un peu problématique (la clause 2.3 de https://about.gitlab.com/handbook/legal/opensource-agreement/ ), la peur exprimée étant que si mon collègue accepte ça et qu'un membre de la communauté fait une connerie, il se retrouve à payer 36 000 US$ de sa poche.
D'autres ont pointé que l'accord est sur une durée de 1 an, donc ça fait beaucoup de paperasse, et j'aurais tendance à dire que c'est 1 an, pour le cas ou il faut serrer la vis encore plus.
Pour reprendre Ian Fleming, 1 fois est un hasard, 2 fois est une coïncidence. 3 fois est une action de l'ennemi.
Pour reprendre Ian Fleming, 1 fois est un hasard, 2 fois est une coïncidence. 3 fois est une action de l'ennemi.
J'aime beaucoup le modèle commercial de GitLab (vraie concurrence sur leur code, tout le monde peut faire la même chose que eux contrairement à d'autres libres mais font du proprio que les autres ne peuvent pas faire "grâce" aux limites imposées aux autres mais pas eux de la GPL), et pensais petit à petit amener ma pub (la partie gratuite, c'est un échange de bons procédés : leur taf contre les afficher) sur eux plutôt que GitHub, mais la confiance à long terme que ma pub est assez intéressante pour eux en prend un gros coup après les coups précédents.
Sérieux, qui peut penser que tout irait bien à supprimer du code, des URLs qui doivent être stables dans le temps???
GitHub/Microsoft gardera donc ma prestation publicitaire.
Comme tu dis, on peut faire des erreurs, mais la c'est trop d' "erreurs", ils ont sacrément besoin de revoir leur relation avec leurs apporteurs d'affaires. On peut monter grâce à ces apporteurs d'affaires, on peut aussi descendre si ils vont voir ailleurs car se considèrent pas assez pris en compte, Mozilla par exemple a déjà pu le constater à ses dépends.
J'ai vu l'ajout dans le lien cité, mais ce n'est pas le sujet.
Le sujet est qu'ils y aient pensé.
A noter que dans les tweets le PDG parle d'actions comme un fork qui pourrait (gloups) désactiver la congélation, mais pas la lecture du repo en soit, donc ça reste quand même problématique que de ne pas regarder la notoriété en lecture de repo, leur réponse est en fait presque pire, ils montrent que la seule chose qu'ils ont compris est que le "peuple" est fâché et qu'ils doivent trouver un moyen de limiter la contagion, pas que leur choix est problématique sur le fond.
Je ne n'étais pas complétement réveillé en lisant ce matin, mais j'ai cru voir un tuite qui disait que toute lecture (même un simple git clone) pourra être vu comme une preuve de vie (ou activité ?) J'ai l'impression que ce n'est pas encore bien clair (mais je viens de lire qu'il y a eu un MR de code) ou plutôt qu'ils et elles sont en train de rétropédaler ou arrondir les angles.
Ceci dit, bien d'accord avec toi que le fait d'y avoir pensé jette un trouble certain et que le mal est déjà fait : avant la fin du mois j'aurais migré chez petit mou (je plaisante, je vais juste y faire miroir et tenter de trouver d'autres forges pour multiplier mes sauvegardes …tant pis pour les ressources.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Côté entreprises t'as soit les droguées de Jira, soit celles qui installent leur propre instance GitLab.
Dans une grande entreprise, les deux ne s'excluent pas. Et plusieurs instances différentes de GitLab d'ailleurs. En plus de plusieurs groupes sur GitHub.com. Et probablement d'autres encore ailleurs.
De même, éviter de dépendre de projets stockés sur gitlab.com, et qui pourraient être trop peu actifs.
Le gestionnaire de version utilisé par tes dépendances, c'est pas vraiment ton sujet. Tous les services de dépôt se réservent le droit de wipe ton projet à leur discrétion et en auto hébergé tu n'a aucune idée de la qualité de l'hébergement et de si celui qui gère ça pas péter une durit demain. Seul les organisations comme Apache, Eclipse et peut-être GNU font quelque chose pour ça.
Le problème en question c'est amha de dépendre d'un code peu ou pas supporté, est que si tu a personne pour s'assurer que le dépôt soit up, tu as probablement pas plus de bras pour renouveler les noms de domaine, mettre à jour les certificats, vérifier les failles des dépendances,…
Mais ce n'est pas parce que le code n'est pas modifié qu'il est peu supporté.
J'ai des roles ansibles triviaux que j'ai pas eu besoin de toucher et qui marchent encore. Ils sont sur ma propre forge, donc j'ai pas le souci, mais je me vois pas rajouter 1 commit tout les ans pour un truc dont le seul but est de faire un include de 3 roles.
Et bon, il faut aussi voir le timing de tout ça, tu dépends de code mort, tu préféres qu'on te le dise, et que tu géres à ton rythme, ou que tu découvres que la CI ne compile plus, même sur les versions stables, parce que la plateforme l'a retiré ?
Parce qu'on risque de se retrouver avec "left-pad II, le retour"
(j'avais proposé "left-pad de quartier", mais la productrice ne m'a pas suivi)
Mais ce n'est pas parce que le code n'est pas modifié qu'il est peu supporté.
Mais je n'ai pas parlé de code modifié. Déjà quelque soit le dépôt si personne du projet n'est en mesure de maintenir accessible le code (car toutes les forges risques de te sortir pour une raison ou une autre) c'est un problème. Mais comme je l'expliquais c'est un site web qui risque de disparaître parce qu'on a pas renouvelé le certificat ou on a oublié de renouveler le domaine. C'est la porte ouverte à une attaque de type supply chain attack. Parce qu'un attaquant peut récupérer le domaine mettre en place une copie de l'existant sauf qu'il te donne son code par exemple.
Pour le reste, je ne dis pas que ce que fais gitlab ne pose pas de problème, mais qu'avoir comme politique de fuir les projets qui sont sur gitlab n'est pas une solution. Tous les projets qui sont sensibles à ce genre de problème peut poser des problèmes quelques soit là où il est hébergé.
C'est la porte ouverte à une attaque de type supply chain
attack. Parce qu'un attaquant peut récupérer le domaine mettre
en place une copie de l'existant sauf qu'il te donne son code
par exemple.
Oui, bien sur. Mais:
- un nom de domaine qui expire n'est normalement pas automatiquement disponible, donc tu va avoir un souci visible assez vite si tu as une CI, etc. Ensuite, je suppose que tout les registrars ne sont pas Gandi.
un certificat qui expire ne va pas automatiquement résulter en une compromission. Les MITM restent quand même assez rare en pratique. Je pense que ça requiert des moyens assez importants en général digne d'un état, tout en étant non utilisable pour ce qu'un état va avoir besoin (cad d'une cible précise avec un timing précis, et idéalement, ne pas se faire choper).
mais qu'avoir comme politique de fuir les projets qui sont sur
gitlab n'est pas une solution. Tous les projets qui sont
sensibles à ce genre de problème peut poser des problèmes
quelques soit là où il est hébergé.
Clairement, ça me parait contre productif, je suis d'accord.
Ensuite, il y a une échelle des risques, et la, gitlab risque de grimper d'un échelon. Le bon coté, c'est qu'il me parait facile de vérifier si une de tes dépendances va disparaître de gitlab via leur API.
Peut être s'il n'y a qu'un seul problème mais que tout le reste fonctionne bien. A minima tu as le même problème que left pad.
Ensuite, il y a une échelle des risques, et la, gitlab risque de grimper d'un échelon. Le bon coté, c'est qu'il me parait facile de vérifier si une de tes dépendances va disparaître de gitlab via leur API.
Tu as des suppressions de dépôts chez github aussi et framagit supprime les comptes 6 mois après ta dernière connexion (je sais pas ce qu'il advient de tes dépôts). Tu pourra sans doute trouver des problèmes avec bitbucket aussi. Hors organisations comme Apachele problème existe et est relativement proche quelque soit la solution.
et framagit supprime les comptes 6 mois après ta dernière connexion (je sais pas ce qu'il advient de tes dépôts).
Il m'est pourtant arrivé de rester plus de six mois sans me connecter et mon compte est toujours actif. J'étais même en train de me demander si je ne vais pas rapatrier mes dépôts Gitlab vers Framagit mais là tu jette un saut glacé…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par barmic 🦦 .
Évalué à 2.
Dernière modification le 04 août 2022 à 23:28.
Ensuite, combien de fois est ce que ça a été appliqué ?
Aucune idée mais si cette nuit ça devient systématique, il faudra pas chouiner parce que c'est un usage hors CGU et ils ont déjà prévu de t'envoyer bouler si tu moufte. Je trouve que c'est à mettre en lumière avec le mouve que compte faire gitlab.
Si maintenant je donne mon avis.
Personnellement je trouve que le fait que la règle s'applique généralement pas/au doigt mouillé crée de l'arbitraire qui me dérange sincèrement. Si ça se trouve ils font le nettoyage manuellement de temps en temps au moment où ils changent de serveur. De quoi te retrouver le bec dans l'eau après t'avoir bien donné l'habitude de l'usage.
Parce que si on va par la, Framasoft se réserve le droit de fermer le compte même plus jeune que 6 mois (sur la même page)
Tout à fait et c'est la raison qui fait que je n'utilise pas framasoft. Je trouve encore une fois personnellement cette règle problématique, mais comme ils le disent je vais voir ailleurs.
Là je parle de framagit en lui-même tu trouvera des choses de ce genre dans toutes celles que je connais.
Tu as des suppressions de dépôts chez github aussi
bien sur, mais il y a une différence entre "l'admin efface les dépôts dans des conditions exceptionnels" et "la politique est d'effacer systématiquement des dépôts".
J'ai jamais eu un dépot qui a été effacer par github ou gitlab pour le moment. Par contre, si ce que je comprends est mis en place, j'aurais sans doute du code à moi qui va disparaître si je fait rien (et pourtant j'utilise ce code, et je pousse régulièrement sur gitlab.com).
J'ai des roles ansibles triviaux que j'ai pas eu besoin de toucher et qui marchent encore. Ils sont sur ma propre forge, donc j'ai pas le souci, mais je me vois pas rajouter 1 commit tout les ans pour un truc dont le seul but est de faire un include de 3 roles.
Idem, de petits rôles Ansible qui n'ont pas encore besoin d'être modifié ; mais certains des miens sont sur cette forge publique et je trouve que ça n'a pas de sens de devoir ajouter un commit non nécessaire ou ouvrir un ticket pour la forme etc.
Dans le même esprit, on a des dotfiles qui peuvent ne plus bouger pendant longtemps et qu'on a plaisir à cloner sur toute nouvelle machine où le besoin s'en fait sentir. Du bien vivant pour moi, mais mort d'après leur définition ; ça pique fort.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
En effet, difficile de savoir ce qu'il en est réellement.
D'un côté, il y avait une MR récemment terminée, qui prévoyait exactement ce qui a fuité. De plus, vu l'avis de réunion dévoilé par TheRegister semblait indiquer que la décision était déjà plus ou moins actée.
D'un autre côté, ce n'est pas une communication officielle, et peut-être qu'une réunion en interne aurait changé la décision finale.
Je pense qu'il y a eu une réunion pour dire "la décision est final", quelqu'un a fuité l'info à la presse pour faire changer d'avis car l'idée semble désastreuse, et la personne en charge de la décision a du changé d'avis.
# Pire des options
Posté par Christophe . Évalué à 10.
Je ne comprends pas comment cette décision pourrait être bénéfique à GitLab.
Le signal envoyé ici, c'est "n'utilisez plus gitlab.com pour stocker des projets potentiellement peu actifs". Donc, plus aucun projet perso, par exemple, et en fait, plus rien, car un an c'est très court.
De même, éviter de dépendre de projets stockés sur gitlab.com, et qui pourraient être trop peu actifs.
Pourtant il y a d'autres voies possibles:
- archiver ces projets (et non les supprimer)
- augmenter le prix de la solution commerciale
- diminuer l'espace offert gratuitement
Je parie qu'il y aura rétro-pédalage sous peu. Mais le mal est déjà fait… Microsoft se frotte les mains.
[^] # Re: Pire des options
Posté par Élafru . Évalué à 5.
Il ne s'agit pas vraiment d'un choix fait librement :
Si GitLab était pas en galère financière, je pense pas qu'ils seraient à la chasse aux projets inactifs.
Ils arrivent déjà pas à la vendre. Côté entreprises t'as soit les droguées de Jira, soit celles qui installent leur propre instance GitLab.
Après c'est vrai qu'un an c'est assez court. Sur un malentendu ou un petit oubli, on va vite devoir dire au revoir à son projet perso. Mais d'un autre côté, personne ne va penser à supprimer lui-même son dépôt de TP d'algorithmique qu'il a fait y'a 7 ans.
[^] # Re: Pire des options
Posté par Christophe . Évalué à 3.
Je me demande tout de même quel serait le gain s'ils passaient simplement à un archivage. Normalement cela divise le coût par 10 (ils utilisent le Google Cloud), ce n'est pas négligeable…
[^] # Re: Pire des options
Posté par Misc (site web personnel) . Évalué à 7.
Ensuite, 1 million par an, c'est pas non plus la mer à boire. C'est 0.4% du chiffre d'affaire 2021 d’après Wikipedia.
Sur 2000€ de revenue net mensuel, ça serait l'équivalent de dépenser 8€ par mois. C'est moins qu'un abo netflix ou une pizza.
[^] # Re: Pire des options
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6.
Et les dégâts en terme d’image sont tels que l’opération ne me semble clairement pas rentable.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pire des options
Posté par Misc (site web personnel) . Évalué à 7.
Mais Gitlab n'est pas à son coup d'essai en 2022.
Par exemple, ça, c'était il y a quelques mois:
https://about.gitlab.com/blog/2022/03/24/efficient-free-tier/
Ça a fait grincer des dents mes collègues qui bossent sur libvirt, car les nouvelles conditions semblent un peu problématique (la clause 2.3 de https://about.gitlab.com/handbook/legal/opensource-agreement/ ), la peur exprimée étant que si mon collègue accepte ça et qu'un membre de la communauté fait une connerie, il se retrouve à payer 36 000 US$ de sa poche.
D'autres ont pointé que l'accord est sur une durée de 1 an, donc ça fait beaucoup de paperasse, et j'aurais tendance à dire que c'est 1 an, pour le cas ou il faut serrer la vis encore plus.
Pour reprendre Ian Fleming, 1 fois est un hasard, 2 fois est une coïncidence. 3 fois est une action de l'ennemi.
[^] # Re: Pire des options
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
C'est clair qu'on ne pouvait pas mieux s'y prendre pour faire fuir les comptes dormants vers µ$ dont l'offre gratuite est déjà pas mal alléchante.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pire des options
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 05 août 2022 à 09:00.
J'aime beaucoup le modèle commercial de GitLab (vraie concurrence sur leur code, tout le monde peut faire la même chose que eux contrairement à d'autres libres mais font du proprio que les autres ne peuvent pas faire "grâce" aux limites imposées aux autres mais pas eux de la GPL), et pensais petit à petit amener ma pub (la partie gratuite, c'est un échange de bons procédés : leur taf contre les afficher) sur eux plutôt que GitHub, mais la confiance à long terme que ma pub est assez intéressante pour eux en prend un gros coup après les coups précédents.
Sérieux, qui peut penser que tout irait bien à supprimer du code, des URLs qui doivent être stables dans le temps???
GitHub/Microsoft gardera donc ma prestation publicitaire.
Comme tu dis, on peut faire des erreurs, mais la c'est trop d' "erreurs", ils ont sacrément besoin de revoir leur relation avec leurs apporteurs d'affaires. On peut monter grâce à ces apporteurs d'affaires, on peut aussi descendre si ils vont voir ailleurs car se considèrent pas assez pris en compte, Mozilla par exemple a déjà pu le constater à ses dépends.
[^] # Re: Pire des options
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
Bon, ce n'est pas encore définitif et plutôt que de la suppression ce sera de congelation aux dernières nouvelles.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pire des options
Posté par Zenitram (site web personnel) . Évalué à 3.
J'ai vu l'ajout dans le lien cité, mais ce n'est pas le sujet.
Le sujet est qu'ils y aient pensé.
A noter que dans les tweets le PDG parle d'actions comme un fork qui pourrait (gloups) désactiver la congélation, mais pas la lecture du repo en soit, donc ça reste quand même problématique que de ne pas regarder la notoriété en lecture de repo, leur réponse est en fait presque pire, ils montrent que la seule chose qu'ils ont compris est que le "peuple" est fâché et qu'ils doivent trouver un moyen de limiter la contagion, pas que leur choix est problématique sur le fond.
[^] # Re: Pire des options
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je ne n'étais pas complétement réveillé en lisant ce matin, mais j'ai cru voir un tuite qui disait que toute lecture (même un simple
git clone) pourra être vu comme une preuve de vie (ou activité ?) J'ai l'impression que ce n'est pas encore bien clair (mais je viens de lire qu'il y a eu un MR de code) ou plutôt qu'ils et elles sont en train de rétropédaler ou arrondir les angles.Ceci dit, bien d'accord avec toi que le fait d'y avoir pensé jette un trouble certain et que le mal est déjà fait : avant la fin du mois j'aurais migré chez petit mou (je plaisante, je vais juste y faire miroir et tenter de trouver d'autres forges pour multiplier mes sauvegardes …tant pis pour les ressources.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pire des options
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Dans une grande entreprise, les deux ne s'excluent pas. Et plusieurs instances différentes de GitLab d'ailleurs. En plus de plusieurs groupes sur GitHub.com. Et probablement d'autres encore ailleurs.
[^] # Re: Pire des options
Posté par barmic 🦦 . Évalué à 2.
Le gestionnaire de version utilisé par tes dépendances, c'est pas vraiment ton sujet. Tous les services de dépôt se réservent le droit de wipe ton projet à leur discrétion et en auto hébergé tu n'a aucune idée de la qualité de l'hébergement et de si celui qui gère ça pas péter une durit demain. Seul les organisations comme Apache, Eclipse et peut-être GNU font quelque chose pour ça.
Le problème en question c'est amha de dépendre d'un code peu ou pas supporté, est que si tu a personne pour s'assurer que le dépôt soit up, tu as probablement pas plus de bras pour renouveler les noms de domaine, mettre à jour les certificats, vérifier les failles des dépendances,…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pire des options
Posté par Misc (site web personnel) . Évalué à 6.
Mais ce n'est pas parce que le code n'est pas modifié qu'il est peu supporté.
J'ai des roles ansibles triviaux que j'ai pas eu besoin de toucher et qui marchent encore. Ils sont sur ma propre forge, donc j'ai pas le souci, mais je me vois pas rajouter 1 commit tout les ans pour un truc dont le seul but est de faire un include de 3 roles.
Et bon, il faut aussi voir le timing de tout ça, tu dépends de code mort, tu préféres qu'on te le dise, et que tu géres à ton rythme, ou que tu découvres que la CI ne compile plus, même sur les versions stables, parce que la plateforme l'a retiré ?
Parce qu'on risque de se retrouver avec "left-pad II, le retour"
(j'avais proposé "left-pad de quartier", mais la productrice ne m'a pas suivi)
[^] # Re: Pire des options
Posté par barmic 🦦 . Évalué à 2.
Mais je n'ai pas parlé de code modifié. Déjà quelque soit le dépôt si personne du projet n'est en mesure de maintenir accessible le code (car toutes les forges risques de te sortir pour une raison ou une autre) c'est un problème. Mais comme je l'expliquais c'est un site web qui risque de disparaître parce qu'on a pas renouvelé le certificat ou on a oublié de renouveler le domaine. C'est la porte ouverte à une attaque de type supply chain attack. Parce qu'un attaquant peut récupérer le domaine mettre en place une copie de l'existant sauf qu'il te donne son code par exemple.
Pour le reste, je ne dis pas que ce que fais gitlab ne pose pas de problème, mais qu'avoir comme politique de fuir les projets qui sont sur gitlab n'est pas une solution. Tous les projets qui sont sensibles à ce genre de problème peut poser des problèmes quelques soit là où il est hébergé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pire des options
Posté par Misc (site web personnel) . Évalué à 3.
non, mais c'est le critère annoncé par Gitlab.
Oui, bien sur. Mais:
- un nom de domaine qui expire n'est normalement pas automatiquement disponible, donc tu va avoir un souci visible assez vite si tu as une CI, etc. Ensuite, je suppose que tout les registrars ne sont pas Gandi.
Clairement, ça me parait contre productif, je suis d'accord.
Ensuite, il y a une échelle des risques, et la, gitlab risque de grimper d'un échelon. Le bon coté, c'est qu'il me parait facile de vérifier si une de tes dépendances va disparaître de gitlab via leur API.
[^] # Re: Pire des options
Posté par barmic 🦦 . Évalué à 2.
Pas tout à fait d'après le lien.
Peut être s'il n'y a qu'un seul problème mais que tout le reste fonctionne bien. A minima tu as le même problème que left pad.
Tu as des suppressions de dépôts chez github aussi et framagit supprime les comptes 6 mois après ta dernière connexion (je sais pas ce qu'il advient de tes dépôts). Tu pourra sans doute trouver des problèmes avec bitbucket aussi. Hors organisations comme Apachele problème existe et est relativement proche quelque soit la solution.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pire des options
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Il m'est pourtant arrivé de rester plus de six mois sans me connecter et mon compte est toujours actif. J'étais même en train de me demander si je ne vais pas rapatrier mes dépôts Gitlab vers Framagit mais là tu jette un saut glacé…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pire des options
Posté par Misc (site web personnel) . Évalué à 3.
Pareil. Les conditions n'en parlent pas:
https://framagit.org/-/users/terms
Par contre, ce qui est dit, c'est que Framasoft se réserve le droit de le faire:
https://framasoft.org/fr/cgu
"Framasoft se réserve également le droit de résilier votre compte si vous ne vous connectez pas à votre compte pour une période supérieure à 6 mois."
Ça ne veut pas dire que ça va être fait systématiquement, ni même que c'est fait pour framagit.
[^] # Re: Pire des options
Posté par barmic 🦦 . Évalué à 2.
Alors les conditions d'utilisations spécifiques à framagit que tu pointe commencent par :
Donc c'est explicitement dit que ça s'applique. Par contre la règle ne résilie pas systématiquement. À chacun de faire son choix.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pire des options
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
OK (me voilà azerty.) Merci à vous deux.
(me faudra s'occuper de cela dans les jours qui viennent)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pire des options
Posté par Misc (site web personnel) . Évalué à 3.
Oui, c'est pour ça que je les pointe et que je colle le passage.
Ensuite, combien de fois est ce que ça a été appliqué ?
Parce que si on va par la, Framasoft se réserve le droit de fermer le compte même plus jeune que 6 mois (sur la même page):
"Framasoft se réserve le droit, à tout moment de modifier ou d’interrompre, temporairement ou définitivement, le service avec ou sans préavis."
[^] # Re: Pire des options
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 04 août 2022 à 23:28.
Aucune idée mais si cette nuit ça devient systématique, il faudra pas chouiner parce que c'est un usage hors CGU et ils ont déjà prévu de t'envoyer bouler si tu moufte. Je trouve que c'est à mettre en lumière avec le mouve que compte faire gitlab.
Si maintenant je donne mon avis.
Personnellement je trouve que le fait que la règle s'applique généralement pas/au doigt mouillé crée de l'arbitraire qui me dérange sincèrement. Si ça se trouve ils font le nettoyage manuellement de temps en temps au moment où ils changent de serveur. De quoi te retrouver le bec dans l'eau après t'avoir bien donné l'habitude de l'usage.
Tout à fait et c'est la raison qui fait que je n'utilise pas framasoft. Je trouve encore une fois personnellement cette règle problématique, mais comme ils le disent je vais voir ailleurs.
Là je parle de framagit en lui-même tu trouvera des choses de ce genre dans toutes celles que je connais.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pire des options
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 04 août 2022 à 21:35.
Histoire qu'on ne me dise pas que j'affabule, je cite les conditions générales d'utilisation :
Conditions Générales d’Utilisation
Donc c'est pas systématique mais ça peut. À toi de voir si tu tente ta chance.
Et au cas où, ils disent bien que si ça t'embête va voir ailleurs. C'est même un point mis en avant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pire des options
Posté par Misc (site web personnel) . Évalué à 4.
bien sur, mais il y a une différence entre "l'admin efface les dépôts dans des conditions exceptionnels" et "la politique est d'effacer systématiquement des dépôts".
J'ai jamais eu un dépot qui a été effacer par github ou gitlab pour le moment. Par contre, si ce que je comprends est mis en place, j'aurais sans doute du code à moi qui va disparaître si je fait rien (et pourtant j'utilise ce code, et je pousse régulièrement sur gitlab.com).
D'ou l'idée d'échelle de risque.
[^] # Re: Pire des options
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Idem, de petits rôles Ansible qui n'ont pas encore besoin d'être modifié ; mais certains des miens sont sur cette forge publique et je trouve que ça n'a pas de sens de devoir ajouter un commit non nécessaire ou ouvrir un ticket pour la forme etc.
Dans le même esprit, on a des dotfiles qui peuvent ne plus bouger pendant longtemps et qu'on a plaisir à cloner sur toute nouvelle machine où le besoin s'en fait sentir. Du bien vivant pour moi, mais mort d'après leur définition ; ça pique fort.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pire des options
Posté par GG (site web personnel) . Évalué à 4.
J'ai lu l'article, rapidement, et il est quand même précisé qu'il y aura plusieurs notifications à l'avance aux utilisateurs.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# Software heritage est sur le coup
Posté par Misc (site web personnel) . Évalué à 4.
Donc bien que ça ne soit pas encore officiellement adopté, Software Heritage est déjà sur le coup:
https://forge.softwareheritage.org/T4421
[^] # Re: Software heritage est sur le coup
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Ce sera déjà ça pour les dépôts non privés…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Beaucoup de bruit...
Posté par Psychofox (Mastodon) . Évalué à 5.
…pour pas grand chose finalement.
[^] # Re: Beaucoup de bruit...
Posté par Misc (site web personnel) . Évalué à 5.
Alors, justement, gitlab a fini par répondre:
https://twitter.com/gitlab/status/1555325376687226883
[^] # Re: Beaucoup de bruit...
Posté par Christophe . Évalué à 2.
Ah, voilà, c'est bien mieux. Ils auraient pu commencer par ça, au lieu de faire peur à tout le monde…
[^] # Re: Beaucoup de bruit...
Posté par Misc (site web personnel) . Évalué à 6. Dernière modification le 05 août 2022 à 09:40.
J'invite aussi à lire l'article de "the register" sur le sujet: https://www.theregister.com/2022/08/05/gitlab_reverses_deletion_policy/
Il y a aussi des commentaires intéressants sur https://news.ycombinator.com/item?id=32350180
Par exemple, le code qui efface les projets explique l'idée
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85689
une discussion sur "last_updated_at":
https://gitlab.com/gitlab-org/gitlab/-/issues/366467
[^] # Re: Beaucoup de bruit...
Posté par barmic 🦦 . Évalué à 3.
Techniquement il me semble qu'ils ont aucune communication officielle qui parle de suppression, c'est une fuite anonyme.
Est-ce que c'était un ballon d'essai ou est-ce que c'est un problème de communication ça je sais pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Beaucoup de bruit...
Posté par Christophe . Évalué à 4.
En effet, difficile de savoir ce qu'il en est réellement.
D'un côté, il y avait une MR récemment terminée, qui prévoyait exactement ce qui a fuité. De plus, vu l'avis de réunion dévoilé par TheRegister semblait indiquer que la décision était déjà plus ou moins actée.
D'un autre côté, ce n'est pas une communication officielle, et peut-être qu'une réunion en interne aurait changé la décision finale.
[^] # Re: Beaucoup de bruit...
Posté par Misc (site web personnel) . Évalué à 4.
Je pense qu'il y a eu une réunion pour dire "la décision est final", quelqu'un a fuité l'info à la presse pour faire changer d'avis car l'idée semble désastreuse, et la personne en charge de la décision a du changé d'avis.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.