D'une part, un des cas d'usages est une personne qui est sur Github.com ou sur Gitlab.com, qui utilise leur option Pages pour son blog perso, et qui décide de passer en auto-hébergé. Elle peut s'attendre à pouvoir conserver la même méthode—la disponibilité de cette méthode peut même influencer son choix de logiciel à auto-héberger.
Ensuite, il y a une ambiguité quand on dit "fait sens pour une organisation de 100 personnes", est-ce qu'on parle d'une instance de Gitlab avec 100 utilisateurs, ou alors d'organisations de gens travaillant ensemble de façon ciblée ? (Chez Github c'est clair, "organisation" c'est la personne morale 'foo' github.com/foo; chez Gitlab c'est moins clair, ils utilisent plutôt "Groupes" pour ce concept). Si les développeurs de Framasoft utilise un Gitlab perso pour gérer le code leurs projets, c'est très clairement une organisation (de moins de 100 personnes). Si on parle de Framagit, est-ce que c'est "une organisation" ? Je suis prêt à faire le choix le plus restrictif: j'imagine qu'ils pensent aux instances de plus de 100 utilisateurs1.
Enfin, il y a plein de groupes de gens de par le monde qui font de l'auto-hébergement mutualisé : un groupe de gens qui se connaissent et qui se partagent les coûts et l'effort d'entretien d'un serveur web, éventuellement d'un serveur mail, etc. On est tous d'accord je pense sur le fait que c'est un excellent modèle. Ces groupes peuvent tout à fait avoir l'usage de Pages (cf. premier point: héberger les pages web d'un projet dans le Pages de la forge correspondante c'est naturel, serveur dynamique à côté ou pas), et font dans leur grande majorité moins de 100 personnes—j'appartiens moi-même à deux groupes différents d'une dizaine de personnes chacuns (mais aucun n'héberge d'instance gitlab). Et ce cas d'usage montre bien que l'intérêt de la feature ne dépend pas du tout du nombre d'utilisateurs de l'instance.
1: Il y a un truc très pervers avec les modèles commerciaux des forges fondés sur le nombre d'utilisateurs, et que j'ai mis du temps à réaliser. Ça marche bien pour des structures qui ont des dépôts à l'équipe de développement fermée, ou carrément des dépôts privés. Mais ça ne marche pas du tout pour du développement coopératif libre, à moins d'implémenter la fédération d'instances. Je m'explique : si tu mets un projet disponible sur Gitlab (auto-hébergé ou gitlab.com ou gitlab.inria.fr), tu veux que les gens puissent t'envoyer des propositions de changements (pull/merge requests). Mais aujourd'hui pour envoyer une proposition de changement, il faut un compte sur l'instance de la personne. Du coup si tu as un projet qui a du succès sur une instance gitlab, tu n'as aucun contrôle sur le nombre d'utilisateurs qui vont s'inscrire dessus pour t'envoyer une petite contribution—et tu as envie que ce nombre soit grand. Si tu paies ton hébergement au nombre d'utilisateurs, ou de manière générale si les gens qui développent le logiciel catégorisent les instances en "nombre d'utilisateurs inscrits", ça ne colle pas du tout. Ça aurait du sens si tu avais de la fédération, si pouvais envoyer une proposition de changement d'une instance de Gitlab à une autre. Je pense maintenant qu'il est important d'implémenter ce genre de fonctionnalités. (Le mieux serait d'avoir un format qui marche avec toute forge git, par exemple en utilisant le format de git format-patch, que github par exemple sait très bien produire en sortie (github.com/foo/bar/pull/123.patch).)
[^] # Re: Râler en public
Posté par gasche . En réponse à la dépêche GitLab libère les GitLab Pages. Évalué à 4. Dernière modification le 27 décembre 2016 à 19:50.
Je crois que c'est un peu plus subtil que ça.
D'une part, un des cas d'usages est une personne qui est sur Github.com ou sur Gitlab.com, qui utilise leur option Pages pour son blog perso, et qui décide de passer en auto-hébergé. Elle peut s'attendre à pouvoir conserver la même méthode—la disponibilité de cette méthode peut même influencer son choix de logiciel à auto-héberger.
Ensuite, il y a une ambiguité quand on dit "fait sens pour une organisation de 100 personnes", est-ce qu'on parle d'une instance de Gitlab avec 100 utilisateurs, ou alors d'organisations de gens travaillant ensemble de façon ciblée ? (Chez Github c'est clair, "organisation" c'est la personne morale 'foo' github.com/foo; chez Gitlab c'est moins clair, ils utilisent plutôt "Groupes" pour ce concept). Si les développeurs de Framasoft utilise un Gitlab perso pour gérer le code leurs projets, c'est très clairement une organisation (de moins de 100 personnes). Si on parle de Framagit, est-ce que c'est "une organisation" ? Je suis prêt à faire le choix le plus restrictif: j'imagine qu'ils pensent aux instances de plus de 100 utilisateurs1.
Enfin, il y a plein de groupes de gens de par le monde qui font de l'auto-hébergement mutualisé : un groupe de gens qui se connaissent et qui se partagent les coûts et l'effort d'entretien d'un serveur web, éventuellement d'un serveur mail, etc. On est tous d'accord je pense sur le fait que c'est un excellent modèle. Ces groupes peuvent tout à fait avoir l'usage de Pages (cf. premier point: héberger les pages web d'un projet dans le Pages de la forge correspondante c'est naturel, serveur dynamique à côté ou pas), et font dans leur grande majorité moins de 100 personnes—j'appartiens moi-même à deux groupes différents d'une dizaine de personnes chacuns (mais aucun n'héberge d'instance gitlab). Et ce cas d'usage montre bien que l'intérêt de la feature ne dépend pas du tout du nombre d'utilisateurs de l'instance.
1: Il y a un truc très pervers avec les modèles commerciaux des forges fondés sur le nombre d'utilisateurs, et que j'ai mis du temps à réaliser. Ça marche bien pour des structures qui ont des dépôts à l'équipe de développement fermée, ou carrément des dépôts privés. Mais ça ne marche pas du tout pour du développement coopératif libre, à moins d'implémenter la fédération d'instances. Je m'explique : si tu mets un projet disponible sur Gitlab (auto-hébergé ou gitlab.com ou gitlab.inria.fr), tu veux que les gens puissent t'envoyer des propositions de changements (pull/merge requests). Mais aujourd'hui pour envoyer une proposition de changement, il faut un compte sur l'instance de la personne. Du coup si tu as un projet qui a du succès sur une instance gitlab, tu n'as aucun contrôle sur le nombre d'utilisateurs qui vont s'inscrire dessus pour t'envoyer une petite contribution—et tu as envie que ce nombre soit grand. Si tu paies ton hébergement au nombre d'utilisateurs, ou de manière générale si les gens qui développent le logiciel catégorisent les instances en "nombre d'utilisateurs inscrits", ça ne colle pas du tout. Ça aurait du sens si tu avais de la fédération, si pouvais envoyer une proposition de changement d'une instance de Gitlab à une autre. Je pense maintenant qu'il est important d'implémenter ce genre de fonctionnalités. (Le mieux serait d'avoir un format qui marche avec toute forge git, par exemple en utilisant le format de
git format-patch, que github par exemple sait très bien produire en sortie (github.com/foo/bar/pull/123.patch).)