On parle régulièrement de Github en négatif ces derniers temps: ça centralise tout, ça capture les données, ça bouffe les autres plate-formes d'hébergement de projets libres avec en plus quelques soupçons de misogynie et sexisme en interne. En gros, Github, ce serait pas bien © (et je pèse mes mots!).
Je partage ici ma petite expérience. Pour les plus pressés, vous pouvez sauter directement aux trois derniers paragraphes.
J'ai créé en 2004 une bibliothèque de test unitaires pour le langage Lua : LuaUnit. C'était pour exécuter des tests de non-régression sur le clone de Vim qu'on développait, qui était scriptable en Lua. Il n'y avait pas rien de tel de disponible dans l'écosystème Lua à l'époque, du coup, j'étais tout frétillant d'apporter une vraie pierre à la cathédrale au bazar. Manque de chance, un autre type a fait pratiquement le même logiciel et l'a sorti au même moment que le mien ! Mais c'est pas très grave, il y a de la place pour tout le monde.
Le projet était assez modeste mais fonctionnait correctement pour ce qu'il devait faire. Je l'ai hébergé sur le site de mon ami qui sert à publier nos diverses contributions ( www.freehackers.org ) et sur luaforge, qui voulait devenir le sourceforge du langage Lua. J'ai eu des retours d'utilisateurs, et quelques micro-patchs utiles. On m'a même proposé de m'associer à l'écriture du framework de test pour the Kepler project, un système complet de packaging pour Lua mais j'ai pas pris le temps de m'investir là-dedans, LuaUnit restait pour moi un mini-projet passe-temps.
Ensuite, le temps a passé, notre clone de Vim est mort, le suivant que j'ai refait dans mon coin n'est jamais né, j'ai fait encore d'autres bouts de logiciels libre à droite à gauche, je me suis mis en couple, j'ai pris de galon dans la vie professionnelle et j'ai complètement laissé tombé LuaUnit. Grace à LuaForge, je recevais quand même de temps en temps des mails d'utilisateurs me demandant d'ajouter des fonctionnalités que j'ignorais faute de temps et de motivation. J'ai intégré un patch pour le portage vers Lua 5.1 parce que le 5.0 commençait à se faire vieux, et j'en ai profité pour faire une petite migration CVS vers Mercurial mais c'est tout. En 2007, un quidam m'a demandé s'il pouvait forker et sortir une v2 avec des fonctionnalités que j'avais pas. J'ai accepté à condition qu'il change le nom. Son fork n'ai jamais apparu dans la nature, mon attitude l'a peut-être refroidi…
Après, encore plus de temps a passé. LuaForge a cessé d'être maintenu, et de 2009 à 2012, plus personne ne s'est intéressé au projet. Il mourrait tranquillement comme des milliers d'autres logiciels libres. Ça me serrait le cœur, d'autant plus que j'avais encore un ou deux patch datant de 2008 à intégrer, mais vraiment, j'avais pas le temps avec maintenant un enfant, une vie de famille, beaucoup de boulot, etc etc.
En 2011, un type a carrément importé mon projet sous GitHub, créé son fork et sorti une v2. Tout ça sans même m'envoyer un mail de politesse. J'ai laissé faire mais j'ai pas trop aimé: il y avait maintenant un LuaUnit v2 qui n'était plus le mien. C'est bien que quelqu'un fasse vivre ce logiciel, mais LuaUnit, c'était normalement mon bébé. Grrrr.
Et puis est arrivé l'année 2012 avec plusieurs évènements: Luaforge a fermé ses portes et migré tous les dépots vers GitHub. Puis j'ai reçu une contribution pour ajouter une sortie des tests au format TAP, pour de l'intégration sous Jenkins. Faire le lien entre un vieux projet à l'agonie et un truc aussi moderne et hype que Jenkins m'a bien plus.
Côté temps libre, tous mes projets libres étaient à l'abandon depuis longtemps et j'étais frustré de ne plus rien faire. J'avais besoin d'un petit projet auquel je pourrai consacrer quelques heures par mois, mais qui serait quand même utile. LuaUnit était le candidat idéal: stable, petit mais suscitant de l'intérêt, avec un potentiel d'utiliser des trucs hype. Je suis allé voir où en était le fork v2 sous GitHub: il était plutôt à l'arrêt. Bien, ça veut dire qu'il y avait de la place pour faire de nouveau avancer LuaUnit sans se marcher sur les pieds.
J'ai donc pris une grande décision cet été 2012: je ferai revivre LuaUnit, sous GitHub ! J'allais en faire un projet de haute qualité: bien documenté, bien testé, moderne (voire même hype avec Jenkins) et dynamique. J'enterrerai de honte le salaud qui a osé forké mon projet sous Github avec un projet plus mieux que le sien. Ce serait la revanche de mon ego de développeur libre!
J'ai quitté à regret mercurial (snif), puis la plate-forme d'hébergement de mon ami (snif) et j'ai tout migré sous Github. J'ai integré le patch pour Jenkins et sorti une version dare-dare. Ensuite, j'ai repris le développement de LuaUnit. C'était un vieux coucou, il avait bien besoin d'un coup de lifting: beaucoup plus de tests, simplification du code, correction de bugs à gauche à droite. J'en ai profité pour rendre facile l'ajout d'un nouveau format de sortie.
Et là, j'ai commencé à bénéficié de l'effet GitHub. Automne 2012, on m'a ouvert un bug; printemps 2013, deux contributeurs, l'un pour des correctifs à droite à gauche et un packaging dans Debian, l'autre pour une autre fonctionnalité majeure (toute proportion gardée pour logiciel de 5000 lignes): une sortie en XML. Sur mon hébergement précédent, il y avait moyen de reporter des bugs officiellement (avec un Redmine) et de m'envoyer des patchs en tirant partie de Mercurial. Mais rien de cela n'est arrivé en 3 ans. Alors qu'en 8 mois sur Github, j'ai obtenu des bugs et patchs de très bonne qualité, à jour, facile à intégrer. L'effet GitHub a continué, depuis 2012, j'ai eu 25 Pull Requests, toutes intéressantes et 17 bugs ou demandes de fonctionnalités. J'ai 3 développeurs engagés qui répondent aux bugs ouverts, suivent ce que je fais et proposent des améliorations. Ça m'a bien remotivé pour continuer à faire vivre LuaUnit.
En plus des contributions pures, Github donne accès à un écosystème pratique: la mise en place de l'intégration continue pour Linux sous Travis CI m'a pris quelques heures. A peine plus longtemps pour la même chose sous Windows avec AppVeyor. Côté doc, j'ai utilisé readthedocs pour rendre la doc facilement accessible. Maintenant, j'ai 3 beaux badges qui montrent que mon projet est en intégration continue. Prochaine étape, un badge pour la couverture de code et je serai au top de l'intégration continue.
En conclusion, Github, pour mon projet et moi, ça a fait beaucoup de bien: des contributeurs, des reports de bugs, des développeurs engagés, des services pour améliorer la qualité de mon projet et une motivation regonflée à bloc. L'effet est bien due à la place proéminente de Github et à la centralisation des projets sur ce réseau social, les principes mêmes qui sont dénoncés comme des problèmes du service Github. L'écosystème autour de Github est d'une bonne qualité en rend des services inestimables. Je trouve ces points sous-estimés dans les « Gitlab fait pareil » . Sous Gitlab, LuaUnit serait encore ce qu'il était il y a 3 ans: un projet agonisant.
# Backup
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
Je me demande si une solution n'est pas d'avoir une version du code (et des outils ?) sur Github pour profiter de l'effet « réseau », et d'avoir une copie de ses données synchronisée ailleurs au cas où Github décide de faire n'importe quoi.
Autant c'est facile pour le dépôt lui-même (Git est conçu pour ça), autant pour d'autres éléments c'est plus délicat, même avec un outil comme une instance personnelle de GitLab.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Backup
Posté par freem . Évalué à 10.
Le vrai problème au fond, c'est celui de l'identification.
Je veux dire, dans un monde quasi-idéal quasi-peuplé de gens quasi-parfaits selon la théorie des auto-hébergionistes (ceux qui veulent nous convaincre que tout le monde doit héberger son site et ses mails soi-même parce que la centralisation c'est le mal… je ne mets pas tous les gens qui gèrent leur hébergement eux-même dans ce panier, je précise) les contributeurs potentiels devraient avant tout créer un Nième compte avec un Nième mot de passe (je ne connais encore aucun site qui utilise des clefs ssh pour remplacer les login/pass classiques… par exemple) différent bien sûr, au cas ou il y ait une Oième faille de sécurité qui fait que l'attaquant pourrait leur piquer tous leurs codes sources libres (sigh) ou non ( nous sommes tous des génies en puissance, pourquoi ne pas faire fortune? ) sur tous les sites sur lesquels ils sont inscrits.
Dans la pratique, ça se résume soit à:
À noter, ce sont des situations que j'ai vécu. Et quand je reçois un mail d'un contributeur, je répond systématiquement, même si je suis parfois en retard sur mes mails de plus de 2 semaines (mes mails persos je les consulte pas assez souvent).
[^] # Re: Backup
Posté par ohm . Évalué à 1.
Pour pallier à ton problème de « n-ième compte/mot de passe », je t'invite à adopter d'urgence un gestionnaire de mots de passe avec son greffon Firefox.
[^] # Re: Backup
Posté par ohm . Évalué à 3.
Et ne surtout pas utiliser un mot de passe générique (surtout si tu as fréquenté le forum de Linux Mint) !
[^] # Re: Backup
Posté par Sufflope (site web personnel) . Évalué à 2.
Et pour pallier ton problème de transitivité verbale je t'invite à adopter d'urgence un Bescherelle.
[^] # Re: Backup
Posté par freem . Évalué à 1.
1) je n'utilise pas firefox.
2) je n'aime pas ce type d'outils. Mes mots de passe sont générés en fonction de données du site et de l'importance que j'accorde aux données sur le site (les sites sur lesquels je n'ai aucunes données ont un mot de passe "classique" identique, les autres un pass unique, mais ils sont vachement moins nombreux…). Pourquoi je n'aime pas? parce que quand on te pique le pass maître, on connais tous tes pass. Sans parler du besoin de faire des backup (certes, c'est de toute façon une bonne pratique, mais je suis une feignasse sur mes machines perso) tandis qu'avec la mémoire, pas besoin de backup (par contre oui, si d'un coup tu deviens amnésique ou si tu passes l'arme à gauche, pour un pass qui sert à d'autres, c'est balo…).
[^] # Re: Backup => il y a de l'idée
Posté par bobo38 . Évalué à 1. Dernière modification le 08 mars 2016 à 09:47.
J'adore ton idée d'identification par clef ssh pour remplacer les mots de passe, c'est une super idée.
[^] # Re: Backup => il y a de l'idée
Posté par gouttegd (site web personnel) . Évalué à 7.
Le protocole TLS permet ça depuis ses débuts (pas avec une clef SSH mais avec un certificat X.509, qui est en gros une clef avec quelques métadonnées autour et une signature), c’est l’authentification du client.
C’est pris en charge à ma connaissance par la plupart des serveurs web et par la plupart des navigateurs… et c’est complètement inutilisé.
En France, le fisc avait utilisé ça à une époque pour la connexion des télédéclarants, ils ont rapidement fait marche arrière. Trop de gens qui ne comprenaient pas comment ça marchait, et qui ne savaient pas quoi faire de leur certificat. (C’est une leçon à retenir pour ceux qui veulent la mort des mots de passe, au passage : peu importe votre solution, si elle est plus compliquée pour l’utilisateur que « taper un mot de passe dans un champ », ça ne marchera jamais, ou en tout cas pas au-delà d’un public averti.)
Ça reste néanmoins une « super idée », personnellement je m’en sers autant que possible (je m’en suis servi par exemple pour protéger l’accès à l’espace d’administration d’un site SPIP).
[^] # Re: Backup => il y a de l'idée
Posté par diorcety . Évalué à 2.
C'est pour ça qu'une smart card PKCS#11 peut être une solution, il te faut un simple mot de passe pour la débloquer. Reste que ce n'est pas répandu et que personne n'a de lecteur… Et encore mieux un lecteur pinpad …
[^] # Re: Backup => il y a de l'idée
Posté par barmic . Évalué à 2.
Il faut en plus le bon driver dans ton navigateur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Backup => il y a de l'idée
Posté par dj_ (site web personnel) . Évalué à 6.
C'est ce qu'on utilise en Belgique, basé sur la carte d'identité
On va sur un site web, ça ouvre une page pour l'authentification qui se fait via le site du gouvernement, puis on est redirigé vers le site
ça permet de faire des papiers a la commune (demande de document), faire sa déclaration d'impôts, demander sa retraite (+consulter tous les docs genre carrière, et la date de la retraite ), pour la mutuelle santé, signer des documents (valeur légale) etc
Le lecteur de carte ne coûte pas cher (<10€)
Mais aucun site web "normal" ne l'utilise, d'un autre côté je suppose que le gouvernement aurait le nombre de consultation du site…
[^] # Re: Backup => il y a de l'idée
Posté par claudex . Évalué à 3.
Par contre, pas mal de site utilisent une applet Java pour faire l'authentification, ce qui pose problème avec de plus en plus de navigateur.
Ma banque l'offre comme méthode d'authentification.
Pourquoi ?
« 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: Backup => il y a de l'idée
Posté par oinkoink_daotter . Évalué à 3.
Les logs OCSP pourraient donner pas mal d'info ?
[^] # Re: Backup => il y a de l'idée
Posté par claudex . Évalué à 3.
C'est vrai. (Pour ma défense, personne ne vérifie les révocations de certificats)
« 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: Backup => il y a de l'idée
Posté par barmic . Évalué à 4.
Et c'est normal, parce que c'est vraiment vraiment vraiment très complexe.
Les serveurs web le prennent en charge, cool, mais pour le prendre en compte dans ton code, c'est déjà une autre paire de manche. La mise en place dans le navigateur est compliquée. Coté serveur la gestion connexion/déconnexion n'est pas simple (il faut utiliser un mode où le client n'est pas obligé de s'authentifier). Pour l'utilisateur, transférer son identité sur un autre navigateur n'est pas simple. Tu prends encore plus de pleins fouet les problèmes d'autorité, mais tu peux créer ta propre PKI (on avait dit compliqué ?). On doit renouveler son identité régulièrement (oui les certificats client ont aussi une péremption).
Sur le papier c'est vraiment bien, mais dans les faits il vaut AMHA laisser ça pour les connexions M2M ou de serveur à serveur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Backup => il y a de l'idée
Posté par gouttegd (site web personnel) . Évalué à 3.
Bof, pas beaucoup plus selon moi que toutes les technologies d’authentification à deux facteurs (HOTP, TOTP et assimilés) qui elles sont de plus en plus déployées.
Exporter un fichier PKCS#12 (contenant le certificat et la clef privée associée), l’importer sur l’autre navigateur. Granted, les interfaces pour ça dans les navigateurs ne sont pas des plus intuitives (je suppose que personne n’a travaillé dessus depuis 1997…), mais ce n’est pas insurmontable.
Et comme dit plus haut il y a la solution des cartes PKCS#11, qui permettent d’avoir son certificat sur soi et non dans le magasin d’un navigateur. Chiant à déployer, de demander à tout le monde d’avoir une smartcard ? Pas plus que de demander à tout le monde d’avoir un token USB comme le propose le standard U2F…
Encore une fois, pas plus compliqué que gérer la double authentification par SMS, code TOTP, et tout le toutim. Et ça c’est déployé — et pas seulement par les « gros », même les « p’tits gars » de Framasoft le font.
[^] # Re: Backup => il y a de l'idée
Posté par barmic . Évalué à 3.
Je ne dis pas le contraire.
En s'assurant de ne pas foutre le certificat n'importe où, avec l'espoire que l'utilisateur ne va pas faire sauter le mot de passe du certificat parce que ça va plus vite.
Je ne sais pas ce que fait framasoft, mais pour la plupart c'est les gros le déploient et les autres utilisent les services de ces gros.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Backup => il y a de l'idée
Posté par groumly . Évalué à 2.
La plupart des gens terminent ssl au load balancer frontal, du coup bonne fete des morts pour soit valider l'authentification client et la forwarder au server d'appli derriere, soit router du ssl en aveugle jusqu'au bon serveur d'appli.
C'est pas impossible, mais ca reste loin d'etre simple a mettre en place.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Backup => il y a de l'idée
Posté par claudex . Évalué à 4.
Ajouter un header HTTP ne me semble pas compliqué et pas d'applis gère ça bien. J'en connais plusieurs en prod comme ça.
« 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: Backup => il y a de l'idée
Posté par Moonz . Évalué à 2.
Tu m’intéresses. Comment tu fais en PHP pour accéder au certificat et au résultat de la validation ? La dernière fois que j’ai regardé, yavait strictement rien un tant soi peu normalisé pour ça, fallait le faire à la main à coups de
fascgi_param TLS_CLIENT_CERT $ssl_client_certavec nginx.[^] # Re: Backup => il y a de l'idée
Posté par barmic . Évalué à 3.
C'est comme ça qu'il faut faire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Backup => il y a de l'idée
Posté par gouttegd (site web personnel) . Évalué à 3.
Ça, je ne sais pas. J’ai déployé le site SPIP, je n’ai pas écrit le code. Mais je ne pense pas que SPIP ait même besoin d’accéder au certificat, c’est l’option
FakeBasicAuthdu modulessld’Apache httpd qui fait tout le boulot.Moi tout ce que j’ai fait, c’est configurer le serveur comme suit :
où
client-ca.crtest le certificat qui doit signer les certificats des clients, etmysite.passwdest un fichier de mot de passe de Apache « classique » (tel que généré parhtpasswd) au détail près que le mot de passe associé à un utilisateur dans ce fichier est systématiquementpassword(c’est un mot de passe bidon qui ne sert à rien).[^] # Re: Backup => il y a de l'idée
Posté par freem . Évalué à 2.
La grande question c'est: pourquoi ne pas permettre les 2 à la fois? L'utilisateur choisit la solution qu'il préfère, comme ça les geeks peuvent utiliser ssh, et les autres leur solution faible.
[^] # Re: Backup
Posté par louiz’ (site web personnel) . Évalué à 2.
Ou https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/integration/omniauth.md (qu’on peut voir par exemple sur https://gitlab.com/users/sign_in, avec le logo google, github etc).
Qu’en pensez-vous ? Ça permet d’avoir le compte en 3 clics, et pas de nouveaux identifiants à retenir.
Bien sûr on part du principe que la personne a un compte github, mais on suppose que c’est le cas, vu que la discussion tourne autour du fait que le centralisation de github est un de ses avantages.
[^] # Re: Backup
Posté par Philippe F (site web personnel) . Évalué à 3.
C'est pas que une histoire de compte à créer. C'est aussi que les utilisateurs/développeurs sont déjà familiers avec l'interface GitHub et savent comment ouvrir des bugs et faire des clones. La familiarité et le confort jouent beaucoup dans l'effet de réussite!
[^] # Re: Backup
Posté par freem . Évalué à 2.
La seule raison d'être de mon compte github c'est pour contribuer aux projets des autres. J'ai toujours trouvé l'interface de ce site horrible (les goûts et les couleurs…) et surtout: lente!
[^] # Re: Backup
Posté par RyDroid . Évalué à 1.
C'est moins pire que mettre tout uniquement sur GitHub. Mais c'est un cercle vicieux, si tout le monde raisonne comme cela, tout le monde contribuera à l’attractivité de GitHub. Certes utiliser un autre service permet de se passer de GitHub, mais il y en a plein (GitLab, Gogs, etc) (et c'est bien), mais GitHub continuera d'être de facto la solution la plus intéressante en terme de nombre de potentiels contributeurs. De plus, certaines personnes ne prendront pas cette précaution et mettrons tout sur GitHub, par flemme, non connaissance des problèmes (logiciel non libre, centralisation et ce qui va avec), etc.
Ça risque de mettre du temps, mais je pense qu'au long terme il faudrait un protocole libre permettant la décentralisation et la fédération, ou une extension d'un protocole pour gérer le cas du visionnement des pull requests (XMPP ?). http://blog.schiessle.org/2016/02/12/the-next-generation-of-code-hosting-platforms/
[^] # Re: Backup
Posté par Philippe F (site web personnel) . Évalué à 4.
Peux-tu m'expliquer le problème que pose GitHub en tant que plate-forme populaire d'hébergement de projet libre ? Je trouve perso qu'au contraire, ça résout un problème, ils proposent un hébergement de bonne qualité avec un effet social qui sauve des projets libres.
Et ma parle pas d'appropriation de tes données, on parle de Git, le SCM où tu as en permanence une sauvegarde complète de tout l'historique de ton code sur ton ordi. Ils ne peuvent rien te prendre, tu ne fais que partager avec eux.
[^] # Re: Backup
Posté par totof2000 . Évalué à 5.
Il n'y a pas que le code, mais aussi l'historique des bugs reports, etc …
[^] # Re: Backup
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Et pour ça, il y a des api et des outils existants pour les récupérer. Les wiki, c'est du git aussi. etc. etc..
[^] # Re: Backup
Posté par RyDroid . Évalué à -1.
Pour l'instant, mais rien ne te garantit que du jour au lendemain GitHub ne va enlever ou complexifier l'exportation étant donné que tu n'as aucun contrôle sur le serveur.
[^] # Re: Backup
Posté par groumly . Évalué à 5.
Et ben ce jour la, t'arreteras de l'utiliser, et on migrera au nouveau service qui remplira le vide que github aura laisse.
C'est ouf, j'arrive pas a comprendre cette mentalite. Parce qu'il est possible qu'ils fassent de la merde dans le futur, on va s'empecher d'utiliser un outil maintenant?
Arrete d'utiliser linux alors, rien ne te garantit que linus va continuer a ecrire du code open source demain, si on suit ta logique.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Backup
Posté par kantien . Évalué à 2.
Oui, c'est le principe de précaution et il fait partie de notre Constitution depuis Chirac : de peur que ce soit mal un jour, on n'utilise pas ! :-/
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Backup
Posté par Misc (site web personnel) . Évalué à 6.
Tu pars du principe qu'un service va emerger. Mais ça, c'est si github fait tellement de la merde que quelqu'un décide de refaire des trucs.
Par exemple, si demain, y a soit github, soit trois fois rien, et que github décide de bannir tout ce qui a trait à la crypto, parce que raison stupide (remplace "la crypto" par "popcorn time" par exemple). Il se passe quoi ?
Si demain, tel gouvernement contraint de fermer un compte à GH, genre la chine qui demande à fermer un miroir d'un soft libre qui contourne son firewall, il se passe quoi ?
Si demain, une entreprise fait fermer un soft qui démontre l'insécurité d'une de ses solutions, il se passe quoi ?
Si on concentre tout l'infra chez 1 fournisseur, alors, ce fournisseur deviens critique, et tu as beau parler d'autres services, ça va causer des soucis.
Si le projet Lua dont on parle se fait bannir de GH pour une raison quelconque, il va être moins vivace si j'en crois l'article. Alors ouais, le code est encore la, mais c'est une piètre consolation.
Donc oui, c'est une raison suffisante pour au moins donner du souffle à des alternatives, et peut être à rendre github moins centrale d'une maniére ou d'une autre.
Par exemple, gitlab.com permet d'avoir un projet qui est un miroir tenu à jour depuis github, ce qui est déjà un bon début.
[^] # Re: Backup
Posté par barmic . Évalué à 4.
Parce que ça a toujours était le cas pour tous les services qui ont de la valeur. Si ça ferme, un concurrent prend là main ou un nouveau service arrive pour combler le vide.
Pour tout ce que tu décris, il y a déjà des alternatives. Si tu veux vraiment quelque chose de neuf et de solide va regarder du coté des fondations comme Apache ou Eclipse. Ces fondations ont des règles claires et précises et fournissent certains nombre de garanties. Ce ne sont pas des projets communautaires mais la gestions par de multiples entreprises améliore leur solidité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Backup
Posté par Sufflope (site web personnel) . Évalué à -1.
Le mouroir des projets fauxpensource abandonnés ?
[^] # Re: Backup
Posté par barmic . Évalué à 5.
Eclipse (l'IDE) ? Apache (le serveur web) ? Groovy ? Ant ? Spark ? Subversion ? Kafka ? Hadoop ? Tomcat ? Maven ? Spamassassin ? Cordova ? Cassandra ? Zookeeper ?….
Je connais très mal la fondation Eclipse mais pour devenir un top project Apache (sortir de l'incubateur), il faut (entre autre) que le projet soit assez vivace.
Et puis reprocher à la fondation Apache de recevoir des projets morts alors que, pour sûr ce n'est pas sur github qu'on y trouve des projets morts.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Backup
Posté par Misc (site web personnel) . Évalué à 3.
Les fondations comme Apache ne vont aller que dans des cas précis. Comme tu dis, il y a des règles, notamment d'avoir assez de contributeurs (de boites différentes aussi), ce qui rends ça impropre pour la majorité des projets (mais pas forcément pour la majorité des projets qui ont un impact).
Et oui, y a des alternatives, mais pour le moment, si les gens n'utilisent pas, ça ne va pas influer vraiment sur la décentralisation.
[^] # Re: Backup
Posté par RyDroid . Évalué à 0.
[^] # Re: Backup
Posté par groumly . Évalué à 10.
Tu veux dire, le mec qui quemande des etoiles pour ses projets github dans la plupart de ses posts?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Backup
Posté par RyDroid . Évalué à 3.
Je n'en sais rien. Même s'il le fait, ça n'enlève pas la pertinence de sa réflexion sur GitHub. Son intégrité est une autre question, c'est une question sur la personne et pas sur les idées.
[^] # Re: Backup
Posté par groumly . Évalué à 3.
Ben un pti peu quand meme. Le message qu'il envoit, c'est que la valeur apportee par github est superieure a l'inconvenient de centralisation, ce qui demonte un peu son argumentaire (et le tien aunpassage).
'fin si on le considere pertinent, ce qui a l'air d'etre ton cas.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Backup
Posté par steph1978 . Évalué à 4. Dernière modification le 31 mars 2016 à 10:47.
Une société privée se retrouve en position dominante avec dans un premier temps l'intention de faire le bien (sauver des petits projets libres, permettre une recherche efficace sur le web, retrouver ses copains de lycée) mais surtout la nécessité de rentabiliser l'argent des investisseurs.
Comme google, facebook, etc. Tous partent d'une bonne intentions, presque altruiste. Mais sont très vite rattrapés par les règles du capitalisme ou l'attrait du pouvoir que leur donne leur position.
Le problème : la plateforme n'appartient pas à ses utilisateurs et ceux-ci n'en ont pas forcément conscience avant que celle-ci ne devienne incontournable.
C'est très piégeux.
# business model de github ?
Posté par Adrien . Évalué à 8.
Le récit est une réponse très intéressante au récit paru il y a peu.
Perso je ne connais pas très bien github, mais sur quoi est basé leur business model ? En effet, je doute qu'il fournisse un service gratuitement, ils doivent donc gagner de l'argent avec… mais comment ?
[^] # Re: business model de github ?
Posté par Kabouin . Évalué à 10.
L'hébergement de projets non open-source est payant.
[^] # Re: business model de github ?
Posté par Philippe F (site web personnel) . Évalué à 9.
Ils vendent aussi une version installable en entreprise de GitHub.
[^] # Re: business model de github ?
Posté par Misc (site web personnel) . Évalué à 4.
Et des goodies, pour que tu payes pour faire de la pub pour eux.
https://github.myshopify.com/
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Expérience enrichissante
Posté par Jona . Évalué à 10.
Vraiment ?
Il n'y a aucune licence libre qui IMPOSE la courtoisie ? … Monde de merde !
[^] # Re: Expérience enrichissante
Posté par Anonyme . Évalué à 3.
meme dans les autres domaines c'est pas tip top, sans juger de la qualité du travail de l'auteur, regarde la futur nouvelle comédie musicale, avec des music d'Obispo
il l'a appris dans la presse qu'il y allait avoir une reprise \o/
[^] # Re: Expérience enrichissante
Posté par Psychofox (Mastodon) . Évalué à 10.
En même temps tel que c'est décrit il recevait des patchs et des bug reports mais ne faisais pas suite…donc question courtoisie, balaye devant ta porte toussa, je comprends qu'un mec qui décide de faire un fork ne prenne même pas la peine de contacter l'auteur original si celui-ci n'a jamais répondu aux requêtes précédentes.
Moi si on me fais un cadeau, je remercie même si ledit cadeau ne me plait pas et que je n'en aurai pas usage.
[^] # Re: Expérience enrichissante
Posté par Philippe F (site web personnel) . Évalué à 10.
Si tu forkes, c'est une bonne pratique de changer de nom. Si tu fais revivre un logiciel à l'abandon comme dans mon cas, c'est plus délicat. Mais un mail de courtoisie me parait le minimum. Ca m'est déjà arrivé plusieurs fois d'être celui qui reprend un projet et j'ai toujours écrit à l'auteur original, parfois avec succès (allez-y les gars, c'est fait pour), parfois avec une réponse plus mitigée (je vais voir si je peux intégrer tes changements puis finalement rien ne se passe). Mais le fork non annoncé, c'est pas très sympa.
Après, je m'agace peut-être pour rien, le modèle de GitHub est basé sur du fork a tout va, le monsieur n'a pas pris la mesure de tout ce qu'il faisait.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Expérience enrichissante
Posté par freem . Évalué à 5.
J'ai une fois utilisé une bibliothèque nommée pluma-framework (gestion de plug-ins utilisables sous windows/Linux pour projets C++).
C'était hébergé sur sourfeforge, pas de contribution pendant un moment, mais après avoir testé un "hello world" (qui était fourni par le dev original) j'ai adopté: simple à utiliser, doc potable (ce qui est trèèès rare dans les lib C et C++ selon moi), code décemment propre (ce qui est rarissime dans ce que j'ai pu lire jusqu'ici) malgré la présence de template (ce qui n'est pas simple à faire, en plus d'être rarissime).
Manque de bol, à l'usage je me suis aperçu que ça manquait de souplesse sur un ou deux points. J'ai codé les fonctions en questions, et comme j'étais dans ma période de transition vers le full command-line, j'ai pondu un CMakeLists.txt pour compiler aussi, je suis pas sûr pour le CPack, par contre, j'ai peut-être pas fait les chose jusqu'à la fin…
En tout cas, j'ai publié le fork comme dépendance du logiciel sur lequel je bossait à ce moment, en "changeant" le nom: j'ai ajouté "-fork" à la fin. Et j'ai prévenu l'auteur.
Tu as raison, je n'avais aucune obligation de prévenir l'auteur, en théorie.
Dans la pratique, j'en avais une: si lui faisais des modifications un jour, autant qu'il prenne en compte les mienne, histoire que je puisse tuer un fork qui n'a que peu de raisons d'être.
Et dans l'idéal, il y a encore d'autres raisons: politesse, respect.
Bien que j'aie choisi le chemin facile, autrement dit le fork avant la discussion, j'ai quand même prévenu (et crédité et encouragé à aller voir dans le README) l'auteur d'origine. Dont la réponse était pour le coup assez indifférente, mais peu importe.
Certes, les licences libres autorisent voire encouragent tout le monde a forker, mais si tout le monde fork à tout va sans même se prévenir, on va perdre des contributions, du temps de travail, de la qualité, tout ça pour rien.
Le modèle centralisé, on peut en dire que ce que l'on veut, mais chez les faitneants, c'est pas le plus populaire pour rien: plus on centralise, plus on peut optimiser les efforts. Malgré que ce soit limité à la condition que tout le monde ait un objectif assez proche. Si l'objectif est trop loin, le libre à la décence de permettre le fork, et que le meilleur gagne!
J'ai comme l'impression que l'on confond trop "libre" et "décentralisé" qui n'ont pourtant rien à voir… et pour cause: ils sont sur des axes différents dans le multivers.
[^] # Re: Expérience enrichissante
Posté par El Titi . Évalué à 3. Dernière modification le 08 mars 2016 à 00:22.
Et ca marche dans les 2 sens. Des fois lorsque le chef de projet est un trouduc, il mériterait son petit fork.
Exemple:
Prenez "Git pour Windows". Tout le monde n'a pas envie de se coltiner le man de Vi pour éditer un commentaire de commit ou faire un rebase interactive.
Il n'apparaitrait pas saugrenu pour attirer des newbies git sous Windows, de proposer autre chose qu'un notepad détaché et de pouvoir utiliser un éditeur de terminal compatible avec le cerveau un être humain correctement formaté ("Vi has two modes and you're in the wrong one" joke inside), par exemple "nano", qui a le bon goût d'être dispo sous MacOSX en plus.
Et bien, quand on voit le prétexte foireux du dev qui ne veut pas juste rajouter un package à son mSys2 et qui fait la leçon, on se dit que des fois un petit fork hostile ça pourrait faire du bien à certains:
https://github.com/git-for-windows/git/issues/587
Parce que bon hé jusqu'à preuve du contraire, Vi ce n'est pas du git non plus.
Pis tant qu'à faire si vous regardez sous le /bin local vous y retrouverez
plein d'outils qui n'ont rien à voir avec git comme du curl par exemple.
Et comme ni cygwin et mSys2 n'ont le bon goût de permettre d'installer des packages depuis rawgit, on se dit qu'on pourrait contourner par exemple avec un petit script bien comme il faut:
https://github.com/transcode-open/apt-cyg
Et là, manque de bol ca marche avec du wget ou du lynx mais pas du curl. Faut-y proposer une pull request à ce dernier pour voir s'il sera plus avenant ?
Ou alors se coltiner tout à la mimine et gagner des XPs en postant son tip (un de plus sur Git) sous StackOveflow ?
Ma bonne dame , un utilisateur de base, qui trouve que git ca ressemble à la grosse Bertha pour écraser une mouche, il a pas que ça à foutre.
Mais après faut surtout pas aller raconter que windows est un citoyen de seconde zone pour git.
Mais, je sais: même pas cap de forker
[^] # Re: Expérience enrichissante
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
En effet, il faut dire que windows est un citoyen de seconde zone pour le développement.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Expérience enrichissante
Posté par Philippe F (site web personnel) . Évalué à 7.
Pour le développement avec Git en particulier. Mercurial avait le bon goût d'être parfaitement fonctionnel sous Windows, sans aucune bidouille à la c** comme git. Sinon, je recommande sourcetree, c'est closed source mais ça marche très bien.
Pour ces histoires de Windows, l'histoire se répète. Il y a quelques années, Gtk a plus ou moins gagné la bataille des GUI préféré pour le dev d'applis sous Linux. Sauf que avec Gtk, Windows est une plate-forme de seconde zone. C'est pas un problème pour une appli qui démarre mais pour toutes les applis très populaires, Windows devient un jour une plate-forme cible et là, le cauchemar commence. Certains persistent (comme Gimp, mais au prix d'un seul développeur, donc d'une grande fragilité de la maintenance) et d'autres laissent tomber pour un choix plus pérenne (Wireshark, Subsurface, GCompris, …).
Pour Git, on est reparti pour un tour. Le support Windows est moyen, Git n'a pas du tout été écrit pour fonctionner sous Windows. Ce qui est donné sous Linux (tout un tas d'outil en ligne de commande) est difficile à avoir sous Windows. Et c'est pas prêt de changer. Mon dernier exemple en date, c'est que si je rajoute git à mon path sous Windows pour travailler sur un projet Git, je peux plus utiliser subversion sur mon autre projet. Git embarque en effet son propre subversion, incompatible avec le mien.
Et contrairement à la bataille Qt/Gtk où Qt a de nouveau ses chances, la bataille Git/Mercurial est perdue depuis longtemps par Mercurial. GitHub ne va a priori jamais rajouter un support Mercurial (tout leur flow est basé sur Git). Même chez Atlassian qui soutenait pas mal Mercurial avec Bitbucket, on laisse tomber Mercurial tranquillement: tous leurs produits sont basés sur Git.
[^] # Re: Expérience enrichissante
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Euh, c'est pas comme si il n'y avait personne qui travaillait là dessus … Y'a eu du gros développement pour le support de Git sous Visual Studio (avec contributions de Microsoft à libgit2 en open-source). Maintenant il y a un salarié Microsoft à plein temps sur « Git for Windows ».
[^] # Re: Expérience enrichissante
Posté par Philippe F (site web personnel) . Évalué à 2.
Ca arrive toujours après la bataille. Le jour où Linus et tous les contributeurs majeurs de git compileront tout leur code sous Linux et Windows, on en reparlera. En attendant, Windows restera à la traine.
[^] # Re: Expérience enrichissante
Posté par barmic . Évalué à 4.
« Après la bataille » ? C'est du libre s'ils veulent contribuer il n'y a pas de soucis (ce qu'ils font), s'ils veulent utiliser des clients alternatifs (comme celui éventuellement proposé dans leur IDE, le client lourd de github, l'excellent sourcetree ou Hg-Git) il n'y a pas de problème.
Linus a écrit git pour les développeurs du noyau linux, lui reprocher que ça ne fonctionne pas sous un OS donné (que ce soit Windows ou AIX) c'est assez risible. Ce qu'on remarque, c'est surtout que git fonctionne très bien sur tout ce qui se rapproche d'un unix. Windows est une exception, ses utilisateurs en paient le prix. C'est très utile quand on est la plateforme qui a le leadership comme pour les jeux vidéos, mais quand on ne l'est plus c'est tout de suite moins rigolo. Les annonces de ses derniers temps semblent montrer que c'est de moins en moins rigolo.
Cette peine que tu as, ne semble surtout ne pas vraiment être partagée. Si c'était si douloureux d'utiliser git sous windows, je doute que github aurait pu s'imposer avec git.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Expérience enrichissante
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Ahem, rien que ça, ça en dit long sur à quel point tu ne t'es pas renseigné sur la question. Ça fait belle lurette que Linus a passé la main sur Git, il ne suit même plus régulièrement la mailing list, il envoie un patch de temps en temps mais je peux t'assurer que le fait que Linus compile Git sous Windows ne changerait strictement rien à la santé de Git pour Windows.
# Libre ?
Posté par Spack . Évalué à 10.
Si je lis bien tu as préféré relancer ton projet de ton côté et au lieu de contribuer à l'autre version plus avancée. J'ai du mal à comprendre. Pourquoi alors publier sous licence libre si personne n'a le droit d'y toucher ?
Le but n'est-il pas justement d'avoir la possibilité de reprendre un projet qui m'est utile mais abandonné par son auteur ?
Ta réaction possessive me semble en conflit avec le but des licences libres.
[^] # Re: Libre ?
Posté par totof2000 . Évalué à 4.
Je ne suis pas sûr qu'il soit judicieux de prendre la dernière phrase que tu cites au premier degré …
[^] # Re: Libre ?
Posté par guppy . Évalué à 8.
Tout d'abord félicitations par contre pour la reprise du projet et de manière générale merci pour le code que tu livres sous GPL.
En gros tu ne l'avais pas touché depuis 2008, 3 ans plus tard un gars a forké. Personnellement je ne vois pas le problème. Légalement c'est correct. L'éthique c'est personnel et ça ne choque pas la mienne.
Le libre c'est ça aussi.
[^] # Re: Libre ?
Posté par Philippe F (site web personnel) . Évalué à 2.
Même un logiciel qui semble inutilisé depuis 3 ans peut avoir une vie sans que ça se voit. En m'envoyant un mail, il aurait aussi pu me remotiver on se serait attaquer ensemble à la prochaine version.
Légalement, bien sur qu'il n'y a aucun problème. Mais la communauté du logiciel libre a des usages sociaux qui ne sont pas uniquement dictés par la loi de la licence. Typiquement, reporter un bug, reporter des modifications à un logiciel, contribuer à son amélioration ne sont pas des obligations mais des actes sociaux qui font partie du fonctionnement de la communauté en général.
Il me semblait avoir indiqué quand même indiquer relativement clairement ce qui m'a posé souci : c'est mon ego qui en a pris un coup. L'ego, c'est justement le truc qui s’accommode mal de gentilles explications.
Après, si ça me posait vraiment un gros problème, j'aurai agi plus fermement. Faire revivre le logiciel est finalement la meilleure façon de réparer mon ego sur ce coup là et de sortir par le haut. Coup de bol, ça a des externalités positives ! Tout est bien qui finit bien.
[^] # Re: Libre ?
Posté par Sufflope (site web personnel) . Évalué à 4.
En faisant quoi du coup ? En changeant pour une licence non libre rétroactivement ?
[^] # Re: Libre ?
Posté par Philippe F (site web personnel) . Évalué à 0.
Quelle idée bizarre! Je n'ai aucun problème avec la licence de mon logiciel.
J'aurai réagi en envoyant un mail en signalant que la politesse quand on sort une version officielle d'un soft qui est le fork d'un autre veut qu'on informe quand même l'auteur original de ce qui se passe. Et je lui aurai parlé des évolutions que j'avais en tête pour la v2 et des problèmes que je connaissais à l'heure actuelle sur la v1 pour qu'il puisse les intégrer à son plan de développement si ça a un sens pour lui. Bref, avoir un vrai canal de communication pour faire des échanges constructifs.
[^] # Re: Libre ?
Posté par Spyhawk . Évalué à 10.
Heu, tu dis toi même que ton soft était léthargique depuis 3 ans. En informatique, ça signifie ni plus ni moins que ton le d;veloppement de ton soft est mort et enterré, et que son seul salut est que quelqu'un d'autre prenne la relève. Alors bon, moi il me semble que tu es bien le seul à blamer ici, et que l'auteur du fork a l'entier mérite de t'avoir mis un coup de pied aux fesses bien mérité! Le logiciel libre, c'est aussi ça! >:P
[^] # Re: Libre ?
Posté par Anonyme . Évalué à 9.
C'est marrant que tu parles d'égo, car en ce qui me concerne, c'est de voir le compteur de fork s'incrémenter sous mes projets github qui flatte le miens.
Un fork est justement un signe que ton travail intéresse d'autres utilisateurs, si tu te sens mal à l'aise à l'idée que d'autres personnes puissent s'approprier ton travail, il vaut mieux ne pas faire de libre en effet.
Mais je comprends tout à fait ton point de vu, juste que je pense que le code qu'on écrit, à partir du moment où il est libre, ne nous appartient plus.
[^] # Re: Libre ?
Posté par guppy . Évalué à 1.
Je suis bien d'accord. Ce qu'on crée vraiment pour nous et uniquement pour nous quand on fait du logiciel libre, c'est l'amélioration de ses compétences en général et plus spécifiquement une expertise sur le logiciel précis qu'on développe. Si il existe quelqu'un qui désire payer pour des modifications, il y a de grande chance pour qu'on soit le mieux placer pour les faire et donc récupérer le pognon.
[^] # Re: Libre ?
Posté par totof2000 . Évalué à 3.
Un code, oui. Un projet (avec un nom et une image), je ne suis pas d'accord. Personnellement, je jour ou je diffuse un projet libre, je garde la main sur le nom (gestion de l'image).
[^] # Re: Libre ?
Posté par Philippe F (site web personnel) . Évalué à 10.
Il y a une grosse incompréhension. Je n'ai aucun problème avec le fait que les gens utilisent mon code et le modifient. Ma licence préférée est d'ailleurs la WTFPL, qui décrit le mieux les contraintes que je veux mettre sur l'utilisation de mon logiciel (en gros, aucune). J'ai choisi BSD parce que ça fait plus respectable et que je suis contre la prolifération des licences mais vraiment WTFPL, c'est le bon esprit.
Par contre, il y a une grosse différence entre utiliser un logiciel, le bidouiller dans tous les sens, le faire évoluer, etc etc et sortir une version officielle d'un logiciel existant en l'estampillant v2. J'avais des plans précis sur ce qui justifierai un passage de la v1 en v2. Et comme je l'ai dit plus haut, le fait que aucun dev ne soit visible n'empêche pas qu'il y a peut-être des choses en cours, qui auraient pu être intégrés à ce fork (typiquement, les 3-4 patch que j'ai reçu par mail).
J'ajoute que je trouve les remarques qu'on me fait assez condescendantes: "ne fais pas de logiciel libre, change la licence". Je rappelle que la communauté du logiciel libre est régie par des licences mais aussi par des usages: reporter des bugs quand on les trouve, proposer des patchs quand on peut développer, contribuer au logiciel libre quand on est une société qui gagne de l'argent avec, etc. Aucun de ces usages n'est réclamé par une licence et pourtant, beaucoup sont choqués quand ils ne sont pas respectés.
De même, j'ai la faiblesse de penser que pour sortir une version officielle d'un logiciel, les usages veulent qu'on en informe l'auteur original. Une anecdote intéressante au passage, lunit - l'autre bibliothèque de test unitaire en Lua qui est sorti en même temps que la mienne - a suivi plus ou moins le même chemin: abandonware, puis fork et rajout de fonctionnalité. Sauf que ce fork a eu la délicatesse de changer le nom en lunitx .
A vous lire, j'ai l'impression que mon travail devrait être entièrement dépassionné, rien dans dans ce que la licence l'autorise ne devrait m'affecter. Ce n'est pas comme cela que je fonctionne, je suis un être humain, mu par des émotions positives comme négatives: fierté de mon travail et joie lorsque j'écris mon premier logiciel, petite honte quand je le laisse pourrir, colère envers moi-même quand je constate mon échec à le maintenir alors qu'un autre y arrive, colère quand un autre réutilise le même nom que le mien pour son travail, fierté de nouveau quand je reprends la main. Le monde où toute émotion contraire à la licence n'aurait pas sa place me semble bien triste… J'espère que ce n'est pas le votre ?
[^] # Re: Libre ?
Posté par guppy . Évalué à 3.
Pas du tout, pourquoi dépassionné ? Tu peux être fier qu'un autre dev considère que c'est une bonne base pour continuer. Tu as participé au mouvement du logiciel libre comme peu le font, en publiant du code sous licence libre. Par contre en licenciant ce code comme tu l'as fait, tu as permis ce fork.
Ton comportement est très humain et se comprend très bien ne t'inquiète pas. Mais tu prends ça trop à cœur. Ok il a pas été très poli, mais ça ça ne l'est pas particulièrement non plus :
Bref, son comportement se comprend, le tien aussi. Beaucoup de bruit pour rien et j'y participe. Je cesse donc d'émettre. ;)
[^] # Re: Libre ?
Posté par Sufflope (site web personnel) . Évalué à 7.
Attention chez github le fork est routinier pour proposer une évolution avec pull request et effectivement peut refléter l'intérêt que suscite le projet ; là on parle de fork "agressif" du genre "je reprends le projet car le mainteneur fait le mort", pas grand chose à voir.
[^] # Re: Libre ?
Posté par Spack . Évalué à 7.
Mouais fork agressif il ne faut pas exagérer. Un fork agressif pour moi, c'est plutôt dans le cas ou l'on fork un projet actif et qu'on cherche à exterminer l'original.
La bienséance aurait voulu que celui qui veut reprendre le projet essaie de contacter l'auteur/le mainteneur orignal. Mais d'ailleurs qui est le mainteneur d'un projet libre ? Celui qui détient le nom de domaine ? Celui qui a le plus grand nombre de commits ? Celui qui a fork prems ?
Bon en cherchant bien on peut trouver je ne cherche pas a excuser l'acte. Mais si un projet dort pendant quelques années on peut imaginer que l'auteur à lâché les rênes et qu'il n'y a plus personne au volant. Encore une fois un mail pour s'en assurer ne peut pas faire de mal sauf si la réponse n'est pas très cordial en retour du genre : "nah t'y touche pas avec tes mains sales, c'est à moi et je veux bien te prêter si tu joues dans une autre cour ie renommes".
[^] # Re: Libre ?
Posté par Sufflope (site web personnel) . Évalué à 4.
C'est marrant je me suis dit "expliquer la différence de sémantique derrière les deux notions de fork, mettre entre guillemets l'adjectif agressif, allez ça suffira je vais pas alourdir le texte pour anticiper les chieurs".
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé
Posté par carlosduvrait . Évalué à -1. Dernière modification le 11 mars 2016 à 16:52.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.