Il publie un outil** complet** qui te permet de répliquer ces fonctionnalités où tu veux, comme tu veux, sans dépendre de leurs serveurs.
Je ne comprends pas ce qui te fait dire cela.
Exemple:
Notons que les deux premiers points (plusieurs vues et une vue pour un groupe) sont destinés à l’édition entreprise de GitLab (et donc aussi à la version en ligne gitlab.com), pas à sa version communautaire.
Ou encore l'intégration LDAP qui je crois est réservée à l'edition pro …
Encore une fois, je comprends que chacun ait le droit de vivre de son travail. Mais expliquez ce qu'il y a de plus respectable à dire:
Si tu veux utiliser mes services hébergés chez toi, payes (tu n'auras pas les sources).sion c'est gratos pour un usage public
et
Si tu veux utiliser tous mes services chez toi payes. Pour les sources tu peux m'aider mais je conserve un avantage commercial sur toi. Toi tu reverses, moi non. Quelle différence au final avec une licence non libre sur du contenu telle que la CC-BY-NC. C'est de la pure hypocrisie.
Github étant contributeur open-source par ailleurs je me permets de répondre à l'auteur du commentaire qui semble avoir un parti pris.:
Le jour où Framasoft grandit, fédère des contributeurs et diverge du core au point que la version commerciale de Gitlab ne pourrait suivre, on en reparlerait ok ?
Vi enfin entre Github et un projet qui fait de l'open-source washing (Contribuez, on est des gentiiiiils et nous on garde le beurre), je vois pas la différence. Autant prendre l'original !! Et les alternatives purement open-source ne manquent pas. Un peu comme la double licence AGPL/proprio qu'un certain habitué nous ressert régulièrement.
Sinon pour ceux qui vont hurler, Github, c'est Electron, Atom, libgit2… sans double licence. Gitlab, à part récupérer les contributions des autres en gardant une marge d'avance, ils font quoi pour le libre ?
Sinon, pour les spécialistes, si on contribue en open-source à réimplémenter leur feature proprio, on risque pas de se prendre un procès ?
Accessoirement, Mattermost, leur partenaire a exactement le même modèle.
Pas que je sois contre, chacun a le droit de vivre. Sauf qu'au final c'est aussi fermé que du bon vieux closed source en terme de concurrence. Bref, sans moi !
Je réfléchis à cette proposition et si ça intéresse quelqu'un j'envisage une série de journaux pour présenter différents workflows avec les tenants et aboutissants de ces choix.
Nous proposons 2 workflows dans ma boîte car 2 méthodes de projets coexistent (Une itérative à la RUP et une agile basée sur SCRUM).
Ils ne sont pas outillés car le but est de ne pas proposer de choses trop compliquées.
Les seules adaptations concernent:
1. Le suivi de la version en prod. On la marque par un tag qu'on déplace plutôt que par une branche
2. Les features branch:
Autant que faire se peut, on les décourage, mais à ceux qui souhaitent vraiment les mettre en oeuvre, on donne quelques consignes:
Qu'elles soient courtes et rebasées y compris sur le serveur de CI (elle sont propres à un seul developpeur). Le workflow ressemble alors à ce que décrit par Crev ici (rebase, push --force, revue éventuelle, merge --no-ff)
S'il s'agit d'epic et que l'on veut vraiment l'isoler dans une branche, il ne faut qu'il y en ait qu'une seule, que l'on réintègre depuis master à chaque commit (merge auto en CI qui casse le build si pb).
Sinon, si tu veux vraiment retrouver ton workflow à la SVN, hormis les 2 commandes de nos compères:
Car l'un à la granularité du dépot, l'autre des fichiers.
De la branche plus exactement.
C'est la raison pour laquelle j'expliquais que dans une migration git avec plusieurs composants (/comp1/trunk, /comp1/v.1.x, /comp2/trunk, …), une des solutions est de créer des branches équivalentes.
Ainsi, tu n'es pas pollué par les commits dans les autres branches, y compris celles des autres composants.
Et par ailleurs, la granularité de SVN pour un commit est par contre le dépôt (une révision par depôt). Mais grâce au fameux buble-up, il est capable de commiter des fichiers qui n'entrent pas en conflit, et tout ça de manière transactionnelle (contrairement à ce bon vieux CVS).
Je voudrais troller, je dirais que t'as l'air assez dogmatique dans ton agilité :)
Ce n'est vraiment pas ton genre :)
Un paramètre crucial dans le feature branch, c'est la durée de vie de la branche. Une branch qui vit 2-4 jours (sur un sprint de disons 2 semaines), c'est pas le bout du monde.
Ton intégration continue s'en sortira, et tes merges aussi.
OK, plus ça dure, plus c'est dur (c'est pas comme le sexe).
Quelle est la granularité alors ?
Une branche par épique ? Y'en a que ça n'effraie pas et qui s'en sortir avec une un merge auto from upstream qui casse le build en CI pour forcer la mise à jour
Au niveau de la US, elles ont parfois du mal à tenir en moins de 4 jours surtout. si comme certains le préconisent on colle juste un gus dessus. Multiplie ça par le nb de US de l'équipe et on nage en plein merge hell.
Au niveau de la task ? Bin quel est l'intérêt d'une branche alors ? Vu que tu intègres des bouts de US, tu prends les mêmes risques de livrer une feature non finie et tu retombes dans l'effet tunnel.
Mais tu donnes quelques éléments:
La revue de code en amont. On n'as pas attendu les feature branch pour en faire. Mais c'est vrai que ca se fait en aval. La question mérite d'être discutée. De la revue de code en amont tu la fais au fil de l'eau lorsque tout le monde commites dans trunk. Tu fais du pair programming, … Suffit de pas puller comme un bourrin et fetcher avant de rebaser. Et le gugusse qui ne respecte pas les coding rules ou qui pète la CI, il va se faire repérer assez vite.
Si je trollais, je dirais que ce worklow te conviens parce que t'aimes bien joué les gros bras ;-)
Le squash pour simplifier le bisect. Si j'étais dogmatique, je dirais que ça ne devrait pas arriver souvent si t'as une batterie de tests qui te préserve de tout ça. Mais franchement 2 itérations de plus sur un bisect (surtout dans un histo linéaire), ce n’est pas le bout du monde. Et si tu bosses pas sur un UI mais sur une API, c'est encore plus simple puisque tu ne te tapes pas tout ça à la mano.
Sinon squash or not squash, c'est un autre débat et il y en a qui sont plus favorables un histo bien découpé
Juste pour être clair - tu comittes/push direct sur master? Genre plusieurs fois par jour?
Indeed, mais comme je suis pragmatique.
rebase -i obligatoire avant un push, et TU+TI mockés en local.
une US ou 2 max à la fois pour toute l'équipe. On est en "scrum" les gars.
Seules les US à risque ont droit à un traitement de faveur. Feature toggling et sinon une feature branch max comme ça pas d'embrouille.
Et pis si vraiment on se ratait, les cadors git qui mergent un refactoring en 2 temps 3 mouvements adeptes du feature branch, ils sont assez frisés pour nous séparer la feature du trunk avec 2 rebase interactive et un push –force, tu ne crois pas ?
Et le mec qui fait un refactoring sans demander si quelqu'un bosse sur la partie refactoree, il mérite un peu des claques, non?
Y’en a encore qui osent refactorer dans ton équipe ?
L'un des gros avantages (qui est commun aux features branches et qui contredit _ il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code et le feature branche_) est que le code de la nouvelle feature, bien que partiellement désactivé en prod, était dans la CI, les tests se jouaient dessus en permanence,
C'est là, je pense, qu'il y a beaucoup de confusions lors des échanges sur le sujet.
Pour certains une "feature branch", c'est une branche locale dans laquelle on commite plusieurs fois. On la ré agence avant de pusher, on la maintient à jour avec le master avec des pull en rebase ou en merge.
Et l'anaphore de barmic prend tout son sens: C'est un espace privé au même titre qu'un workspace SVN et pour pousser l'analogie encore plus loin, les nostalgiques de SVN peuvent se contenter de commit --amend jusqu'au moment du push. Dans mes propos, lorsque je mets en garde contre les feature branch, ce n'est pas de ça dont je parle. Au contraire, travailler dans le trunk ne dispense pas des bonnes manières à coup de rebase interactive.
Pour d'autres (c'est à ça que je fais référence) c'est un espace partagé. C'est là que plusieurs devs pushent sur un serveur, que tournent les tests d'intégrations et que des workflows d'approbation à base de code review pre-merge se mettent en place. Ce n'est pas parce que le serveur d'intégration tourne qu'on fait de la CI (j'y reviendrai). Dans ce type d'espace, on ne peut pas se permettre des rebase en permanence par rapport à master à coup de --force car réécrire l'historique en déplaçant la ref de branche distante a des conséquences sur tous les devs, si la feature n'est pas complète. C'est pour ça qu'on passe par du merge ou par un squash (https://github.com/blog/2141-squash-your-commits).
Un modèle intermédiaire vient avec les outils à la Github et les workflows à la « fork+pull request ». Ici on dispose d’un espace public mais exclusif. On publie sa branche sur le serveur, on peut y faire tourner la CI (détection de branche automatique), mais il reste privatif car dédié à un seul dev en écriture. Le dev recalé lors de la review peut donc republier ses modifs en soumettant sa pull request après un rebase. L’intégration est prise en charge par le serveur en automatique (squash+rebase ou merge, validation par un intégrateur, par quota de reviewer …). Ca convient pour du dev open source avec des contributeurs de tous horizons, y compris occasionnels, mais pour du dev en entreprise autour d’une équipe resserrée ça commence à devenir un peu lourd comme process, pour intégrer au fil de l’eau. En tout cas, si on passe par un intégrateur comme goulot d’étranglement, qu’on ne vienne pas me dire que c’est de la CI. On peut discuter des mérites, mais ce n’est pas de la CI (cf. plus bas). D’autres éditeurs (Atlassian) ont contourné le problème en évitant de passer par la case "fork" et en jouant sur les permissions au niveau des branches du repo central. Ca améliore le truc mais ça reste lourd. Le workflow que tu nous avais présenté dans un journal est dans la même veine même si plus léger (l'exlusivité est une pure convention) et indépendant d’une review ou d’un intégrateur.
Mais la conséquence de tout ça, c’est que la feature est sous la conduite d’un seul gus. Niveau granularité, ça se limite donc plutôt à une task qu’une User Story (sinon repart dans le travers des long lived) et ça rend assez caduque l’argument sur l’intégration d’une US quand elle est prête.
Concernant la CI. C’est pareil, il faut bien s’entendre sur le vocabulaire. Ce n’est pas parce que tu balances une branche sur ton serveur de CI que tu fais de la CI. Le principe de base de la CI, c’est que tout le monde intègre dans la mainline . Je vous renvoie sur un autre lien de Martin Fowler, pour savoir de quoi on cause.
Mais bon, on s’écarte du sujet initial avec l’agilité et les feature branch. Ce qui m’a fait bondir à la base, c’est qu’on en voit toujours nous ressortir le GitFlow comme la solution à tous nos problème y compris en agilité. J’ai exposé quelques arguments pour démontrer à quel point c’est faux et que chaque projet a son contexte et que le workflow universel n’existe pas. Et je suis assez satisfait de découvrir que d’autres ont émis des réserves semblables aux miennes. Je vous invite à les lire car ça rentre bien dans les détails.
Le plus simple au monde, celui qui reste compatible avec SVN et ses limitations (mais nous utilisons Git, … à bon escient):
Le Trunk Base Development.
Une branche pour les gouverner tous.
Ponctuellement, une branche de hotfix peut-être nécessaire, mais les protagonistes de Continuous Deployment la proscrivent et privilégient la mise à disposition de correctifs dans le trunk.
Il est important de dissocier les différents niveaux de maturité en agilité.
Le premier est l'intégration continue. Tout est intégré au fil de l'eau
Le second est le continuous delivery. On fait en sorte que tout ce qui est intégré soit potentiellement déployable (build au vert et tests automatisés à gogo pour s'assurer de la qualité de la livraison)
Le niveau ultime est le continuous deployment. Le déploiement est automatisé lors de chaque build. C'est l’achèvement du DevOps (nous sommes loin de ce niveau de maturité hélas).
Wikipedia explique très bien la différence
Sinon, une autre raison invoquée pour mettre en oeuvre des branches (long-lived) et que je n'avais pas évoquée concerne les migrations techniques.
On peut-être tenté de créer une branche pour migrer vers un nouveau framework ou toute autre raison technique qui affecte son architecture
Là aussi ça devient complexe à gérer. Car il faut systématiquement reporter les évolutions livrées dans la branche de prod vers la nouvelle branche de migration technique.
Une autre stratégie peut-être mise en place. Le "Branching by Abstraction". Ceci consiste à développer une couche d'abstraction dans le trunk puis faire pointer ton architecture dessus, implémenter la nouvelle et basculer dessus. L'avantage c'est que par la force des choses ton architecture devient plus évolutive et par conséquent sa qualité s'améliore (la couche d'abstraction reste).
Et pour conclure, je cite souvent Martin Fowler. Au cas où tu émettes quelques doutes sur la crédibilité du personnage, je t'invite à jeter un oeil à la liste des signataires du manifeste agile
À moins que ce ne soit basé sur quelque chose qui tienne la route, mais j'ai un gros doute :-)
C'est complètement fondé. si on transpose ce raisonnement en politique. Les citoyens se désintéressent de plus en plus de la politiques. Les électeurs FN n'étant pas prêts de renoncer, la probabilité qu'on se retrouve avec Marine au pouvoir augmente.
Steve Ballmer, sauve nous des nazis de l'interface !!!!
J'espère que vous ne bossez pas en agilité dans ta boite ? Auquel cas, ce message ne te concerne pas.
Déjà cette drôle d'idée de reporter toutes les versions de prod sur la branche master et de dédier develop à ça.
Quand un gars arrive dans une équipe pour se joindre aux forces vives, quoi de plus naturel que de bosser dans master. Si je veux connaitre le version de prod, y'a quoi de compliqué de s'appuyer sur une convention de nommage et de lister les tags avec un petit grep des familles.
Ensuite cette manie de créer une branche de release pour la recette et la maintenance. En agilité que ce soit en scrum, kanban, lean ou à fortiori en continuous deployment, on a coutume de réintégrer les demandes de corrections plus tard (sprint suivants). On ne s'amuse pas relivrer des corrections en recette ou en prod sauf cas du hotfix qui est le seul qui nécessite une branche dédié à réintégrer dans la master. Evidemment on automatise un max avec une batterie de test pour qu'une recette ne dure une éternité (test exploratoires). La branche de release avec un environnement stable pour tester est le signe avant coureur que le projet va partir en couille et que les prestataire de monkey tester vont débarquer en masse. Le cône glacé va vous refroidir.
Enfin les feature branch. Le jour où on comprendra que développer à base de feature branche, et pour aller encore plus loin de pull request avec revue online comme veulent absolument nous les refiler Atlassian, Github, Gitlab et consors qui ont tout intérêt a centraliser encore plus les workflowws autour de leurs outils pour nous revendre leur bidules, on aura fait de grands progrès.
L'agilité ça consiste à discuter au plus tôt sur les questions qui pourraient poser problème. La base de l'agilité c'est l'intégration continue. Tout ce qui y contrevient est malvenu. Relisez c'est article de Martin Fowler pour comprendre pourquoi c'est le mal:
(Je l'ai déjà posté plus haut mais là je vais appuyer l'argumentaire). Dans une feature branch,vous retardez l'intégration de vos devs et par delà la découverte de problèmes d'architecture. Vous pouvez vous réalignez régulièrement par rapport à master (merge from upstream) mais il n'en reste pas moins que vous êtes isolés de toutes les features pas encore intégrées et les autres de la vôtre. Ce n'est qu'au moment où vous intégrez que les problèmes arrivent et notamment le big bang merge, les conflits sémantiques et c'est souvent le plus mauvais moment… peu avant la fin du sprint.
Certains parlent alors du mini effet tunnel qui vous fait retomber dans les travers des méthodes traditionnelles, consustant à tout intégrer dans l'urgence et souvent au détriment de la qualité (on n'a pas le temps de refactorer nos tests là, on est à la bourre).
Au fait, reposons-nous la question: Quelle sont les raisons pour lesquelles on souhaiterait mettre en place des feature branch?
La réponse qui vient immédiatement concerne la souplesse que ça nous apporte. On peut décider d'intégrer une feature au moment d'une livraison ou de la reporter si elle n'est pas prête.
Alors déjà, première chose: Pourquoi passer systématiquement par une branche surtout en début de sprint ?
Ensuite, quel est le problème de livrer une feature incomplète … si elle n'affecte pas votre produit ?
Vous voyez poindre la solution qui permet de continuer à développer dans le trunk tout en conservant cette souplesse ? Vous l'avez tous déjà fait un jour. Supprimer un item dans un menu, ou un bouton dans un formulaire…
Ca s'appelle le feature toggling(http://martinfowler.com/bliki/FeatureToggle.html). Vous structurez votre code pour activer ou non des fonctionnalités au déploiement (http://martinfowler.com/articles/feature-toggles.html).
Ceci vous permettra même de valider ou non la pertinence d'une fonctionnalité sur un panel de clients précis ou de les comparer en environnement réel. le fameux A/B testing.
Après, il est vrai qu'une des conséquences est que ça génère de la dette technique, et qu'il faut supprimer le code d'activation lorsque la feature est intégrée ou écartée. Mais il existe des frameworks pour vous y aider.
Alors si vous voyez débarquer dans vos équipes un type qui vous vante les mérites du feature branching, et que c'est peanuts avec git et que Git flow c'est une tuerie, le même qui ne s'est jamais paluché un vrai merge des familles avec du refactoring sur le nom des packages et des classes, les changements sur les schémas de base de données, un conseil … Fuyez !!!
Toujours pas convaincus ?
Peut-être que lui y parviendra.
Tout pareil qu'avec SVN, non ? Quand ton checkout n'est pas à jour, il faut faire un update
Je ne crois pas non. La grosse différence avec SVN c'est qu'avec ce dernier, tu n'es pas empêché de committer si les changesets portent sur des fichiers disjoints. Avec git et tous les DVCS, c'est le cas. C'est inhérent au modèle distribué. Ces fameux commits de merge que l'on se doit de filtrer pour rendre l'historique plus clair ou qui justifient l'existence du rebase.
Ceci peut paraître anodin mais ça a une conséquence importante:
Avec SVN la gestion des composants est beaucoup plus souple. Un repo SVN peut accueillir des modules disjoints et les gérer comme des projets séparés de manière transparente. On n'est pas pollué par les commits des autres tout en bossant avec du trunk dev. Ceci offre beaucoup de souplesse pour faire évoluer son architecture. A un moment, on peut incorporer du code d'un autre composant ou au contraire le séparer … sans perdre l'historique.
Avec git, il faut faire des choix à priori en séparant les composants et utiliser les submodules (ou d’autres solutions équivalentes) avec toute leurs limitations et des problèmes à gérer si ces choix s’avéraient erronés ou si les besoins évoluent. L'autre solution est de dédier une branche par composant avec toute la complexité associée (convention de nommage sur les branches, …).
Je conviens que ceci est assez largement compensé par le fait que la gestion par composant peut se faire au niveau binaire, mais la granularité d'un article de configuration n'a jamais été chose simple et quelquefois la gestion de composants niveau source est incontournable.
« out of date in transaction », sans l'ombre d'une suggestion de comment sortir de la situation,
Grosse mauvaise foi détectée.
J'ai moi aussi l'occasion d'enseigner git à « quelques » novices et même si je n'ai certainement pas tes compétences sur les entrailles du bousin, n'étant pas contributeur sur le projet, je trouve quand même ta remarque assez décalée lorsqu’il faut expliquer pourquoi on se prend un "push rejected: non-fast-forward". C'est assez cocasse d'ailleurs que pour dépatouiller tu confesses d'être obligé de faire appel à ton expertise. Ca prouve la simplicité du bousin. Pour alimenter la réflexion et sans attaque personnelle, voici un article (https://medium.com/@cscalfani/why-experts-make-bad-teachers-ccaed2df029b#.luyizwowj) qui amène à se questionner sur la manière de transmettre son savoir en tant qu’expert d’un domaine
Au titre des choses amusantes aussi, les milles manières de réécrire un historique en multipliant les commandes (rebabse -i, squash, amend, cherry-pick, reset --soft|mixed, …) mais expliquer après que par contre, ils n’ont pas été foutu de séparer le checkout d'un commit et d'un fichier, en 2 commandes distinctes ou de s'accorder sur un nom de commande pour cleaner l'index et qu'il faut en passer par un reset HEAD tellement evident … qu’un bookmark stack overflow de + pour votre collection http://stackoverflow.com/questions/19730565/how-to-remove-files-from-git-staging-area) avec un alias à la clé.
Autre truc amusant, les explications sur les dangers des commandes qui réécrivent l’historique et qu’il faut utiliser avec précaution (amend, reset , …) à cause des push. Alors oui, il y a le --force qui prévient. Oui comme tu l’expliques ailleurs, la force de Git c’est la gestion de son historique local et il faut expliquer au newbies qu’une branche locale c’est un peu comme son workspace git, c’est un espace privé. Mais en centralisé, il y a fallu créer des webhooks ou positionner des options git pour bloquer les conneries. Et on aimerait bien que git soit un peu plus prévenant en amont; comme par exemple des options pour limiter le reset sur commits non pushés. Evidemment ce n’est pas possible puisque git de base doit aussi supporter le mode décentralisé et que dans ce cas rien ne peut être anticipé (je ne sais pas qui a déjà cloné ma branche si je bouge ma ref).
Mais dans tout ça, ce que je trouve le plus savoureux, c'est de me remémorer ces trolls où certains disaient que le fait que git récupère une copie du dépôt en entier était un problème. Surtout pour un workflow centralisé en entreprise, ça n'était pas forcément un choix pertinent. On nous expliquait que grâce à son algo de compression ce n'était absolument pas un problème pour le transfert que le kernel en était une preuve.
Et maintenant, on prend conscience que des projets, ce ne sont pas que des fichiers source mais qu'on a besoin de jeu de données pour les test d'intégration, de stocker des binaires notamment dans le domaine du jeu (artworks) … et que leur place est bien dans le dépôt. Ce ne sont pas des documents Word avec lesquels on explique gentiment qu'il y a d'outres outils pour ça.
Moralité depuis:
* J'ai un collègue admin qui fait la chasse aux binaires dans les dépôts et s'amuse à les cleaner à coup de bfg (comment ça l'historique d'un projet est sacré ma bonne dame ? … Vous ne vous en servez plus, raison de service, Léon le nettoyeur va passer). En terme d’admin, on se croirait revenu au temps glorieux de Clearcase, tient.
* Git prend en charge le fait de partager un même dépôt entre plusieurs workspaces alors qu'on se moquait doucement des DVCS qui le permettaient. (Je conviens que c'est vraiment un nice to have parce qu'une recopie d'un clone en local ça coûte rien en réseau)
* Git étant surtout utilisé en centralisé (merci Github et Atlassian) et v'la tit pas qu'on nous sort du git LFS pour adresser le problème des gros fichiers. Quelle ironie du sort. A chaque checkout, on va vous expliquer qu'il faut être connecté pour récupérer la bonne version du binaire. Allez encore un petit effort et vous allez découvrir la notion de client serveur, de workspace en mode centralisé et qu'un cache pour stocker l'historique, c'est suffisant (Perforce le gère depuis le début). Ok je retire cette dernière phrase qui est de la pure provoc.
L'autre gros soucis dans le cas de workflow centralisé concerne le lock pessimiste. On a beau nous expliquer qu'un outil de gestion de version n'a pas vocation à être un outil de communication, l’argument ne passe pas. Expliquez-moi ce dont vous avez besoin, on vous expliquera comment vous en passer ! (Petit hommage à Coluche, tu nous manques). Lorsqu'on bosse avec des fichiers binaires comme des images, des fichiers qui ne proposent pas leur propre interface de merge (modèle UML, fichiers XML persistants avec une sémantique bien définies), l'argument a du mal à passer et les options --ours et --theirs du merger sont quand même un peu légères. Lorsque tu viens de te chiader l'édition d'une image et qu'un gugusse te balance une modif en même temps, y’a quand même un souci et si on vous rétorque que vous avez qu’à vous parler avant, vous pouvez aussi lui renvoyer que dans ce cas les merges ne servent à rien sur les fichiers source et il suffit de se parler et de revenir à ce bon vieux RCS. SVN avec les properties sur les types de fichiers et le svn lock le suporte au poil. Autre exemple, Talend studio (un ETL) a récemment migré de SVN vers Git pour son studio, suite forte pression client. Ils se sont retrouvés à réécrire un système de lock à part du cvs parce que les mêmes clients ne veulent pas sacrifier sur le lock pessimiste non plus.
Aujourd'hui le bilan est le suivant. Malgré ces mérites indéniables (on est tous d’accord), on se retrouve coincé avec un outil dont la vocation n'est pas le modèle centralisé. On nous explique qu'il le gère, car qui peut le plus peut le moins. Mais du coup des choses basiques qui pourraient améliorer ce workflow seraient incompatibles avec les autres modèles de workflow. Alors on voit émerger de plus en plus de solutions de contournement. Soit, mais s'il vous plait, convenez que SVN est assez adapté pour ce besoin et non, git de base n'est pas toujours aussi adéquat ni en termes de simplicité ni en termes de besoins. A côté de ça, personne ne souhaite revenir sur le confort de rajouter un remote pour bosser sur le même projet entre 2 organisations séparées ou encore la possibilité d'accueillir des contributions ponctuelles avec des pull request mais on est bien au delà d'un simple projet centralisé dans une entreprise. Quand à la possibilité de réécrire son historique avant de pusher, top de choix tue le choix. Pas toujours facile de s'accorder sur la bonne granularité du commit. Entre ceux qui visent la simplicité et veulent pouvoir cherry-picker un seul commit pour reporter une feature, ceux qui veulent pouvoir relire l'historique par petits incréments et trouvent que c'est plus simple en cas de rebase, les protagonistes de la feature branch.
Et voilà encore un nouvel animal de foire, le git series … Si ce n'est pas du cargo cult, en tout cas ça y ressemble parfois.
Pas facile de faire comprendre un newbie qui vient de découvrir les branches, les pull request vendues par les marchands de rêves à la Github/Bitbucket et qu'il veut vous en fourguer partout, que ça contrevient un des principes de bases de l'agilité: l'intégration continue. quPas facile de lui faire comprendre que les features branches n'ont rien d'agile (http://martinfowler.com/bliki/FeatureBranch.html) et venir le voir pleurer lorsqu'il a refactoré comme un porc et se trouve comme un con avec un big bang merge et qu'on doit se taper de le dépanner à coup de stratégies de merge et d'ajustement du "threshold" dans le find-renames.
Avec de grands pouvoirs, viennent de grandes responsabilités…
Moi ce qui me déprime, c'est que maintenant dans le bus, les pénibles qui écoutent du rap à donf auront une vraie excuse pour leur insoutenables exactions, … ils ne peuvent pas se payer des ecouteurs.
Regardez sur internet la définition du second degré.
Pour moi ce journal est un régal et il fait partie de la subculture DLFPienne au même titre que la bronsonisation, la journée de la procrastination (tiens d'ailleurs personne n'en a parlé cette année), les trolls systemd, …
Vu comme ça, la question c'est est-ce qu'on va les laisser crever dans la solitude sous prétexte qu'ils ont eu une vie plutôt sympa ? C'est un peu une manière commode de se défausser selon moi d'un énorme problème.
Ca serait pas mal que tu ailles faire un tour au Caraibes, sur la côte et tous les endroits au soleil inabordables pour les primo-accédant avant de sortir des grossièretés de ce genre.
Quand au système par répartition, bizarrement à chaque tour de la droite on en reprend pour 3 ans…parce qu'il est déficitaire et qu'il va droit dans le mur. Soit on continue à faire des gosses pour le maintenir au risque de faire exploser la planète avec les tensions sur les ressources ou on arrête d'en faire et les générations d'actifs qui arrivent se font encore plus baiser que les précédentes.
Quand à la gauche quand on voit rewind qui défend ce système. Bizarrement, ce fameux contrat va toujours dans le même sens, pour l'équilibre: allongement de la durée de travail, précarisation du contrat de travail (ben oui faut bien les faire bosser ces jeunes cons,, de mon temps …gna gna gna), durcissement des conditions pour l'assurance chômage, …
Il est si sacro saint ce contrat intergénerationnel ? On m'a pas demandé mon avis quand je suis né.
Seuls les suédois ont eu le courage de mettre les pieds dans le plat en baissant les pensions des plus aisés, …oui Madame.
Personne n'en parle ici de peur de perdre la frange d'électeur qui mène ce monde par le bout du nez.
Les mêmes qui profitent de leur "répartition" se sont en plus gavés sur la capitalisation en achetant pour un bout de pain des belles barraques au soleil à une époque où l'inflation leur a permis d'amortir leur prêt en moins de 2. Depuis les conservateurs allemands sont passés par là et ont imposé le contrôle avec la banque centrale.
Et qu'on ne me parle pas de transmettre son patrimoine surtout à gauche… Et les orphelins, les fils de plébéiens ? Elle est où l'égalité des chances ?
Les baisés comptez vous, avec Sarko en 2017 on va vous la remettre encore plus profond.
C'est un cas d'usage intéressant, mais je n'ai rien prévu qui aille dans ce sens. À ton avis, que faudrait-il mettre en place pour répondre à ce cas d'usage ? Comment ça pourrait fonctionner ?
Je n'ai pas précisément réfléchi à ça, mais je voulais d'abord attirer votre attention, afin que vous vous preniez ce besoin en compte et j'essayais de le projeter sur votre architecture.
Toutefois, voici quelques pistes de réflexion
Il faut d'abord élaborer votre système d'ACL pour en tenir compte au niveau de l'API REST mais peut-être aussi coté backend pour plus d'efficience.
Vous définissez la notion de contexte (un peu comme les cercles google) ce qui est très bien. Vous prenez en compte la notion de données cryptées. Pensez à la notion de données anonymisées à ces fins de statistiques. Ca va au delà des "metrics" puisque c'est pour un usage "métier".
Chaque utilisateur pourrait donc décider de l'utilisation de ses données en se basant par exemple sur 4 niveaux
* privé
* restreint (géré par les contextes)
* anonyme (la donnée est accédée en lecture par des traitements mais ne peut pas être associée à l'utilisateur)
* publique
Pour l'implémentation, il me semble que des processus transverses du genre de ceux mis en place par les "metrics avec des dbs dédiées(Redis ou CouchDB) pourraient convenir.
Cependant l'usage est différent puisque ces infos seraient accessibles au niveau des applications hôte. Ceci a donc un impact sur /data
De la même manière, j'imagine que dans votre architecture actuelle un développeur d'application hôte (sauf cas serverless) doit coder une partie backend s'il doit persister des infos partageables entre points d'accès. Il devrait alors pouvoir accéder à votre système d'autorisations sans passer par l'API REST sinon ça va se ressentir sur les perfs. Il devrait donc pouvoir non seulement interroger votre API bas niveau mais aussi pouvoir collecter des données anonymisées et les persister dans ces bases dédiées. Il devra certainement être en mesure aussi de publier les services associés dans un genre d'annuaire (niveau REST et plus bas)
Autre point pour la syndication.
Si j'extrapole votre archi, un système d'annuaire distribué sera mis en place et les échanges passeront par l'API REST.
Là encore un faudra peut-être prévoir des canaux basés sur des abonnements à des événements au niveau Websocket (par exemple pour calculer les indicateurs sur des données anonymisées en agrégeant plusieurs noeuds.
Enfin dernier point, prévoir une couche d'abstraction (API bas niveau incluse) permettrait de mieux cloisonner les application hôtes, voire même d'héberger à terme d'autre langages (bon ça aurait été mieux avec du Java pour cause de JVM ;-).
Merci pour cette clarification … même si je crains que certains choix de design ne vous conduisent à un moment à négliger l'une des 2 cibles.
Voici donc quelques suggestions qui pourraient influencer votre architecture. Je ne suis pas assez technique pour être précis mais je comprends que cette nouvelle architecture vous permettra de scaler en multipliant les instances et même si vous vous défendez d'utiliser des microservices, vous n'êtes pas non plus dans une approche monolithique. Vous explorez une voie intermédiaire.
Il y a 2 aspects qui, me semble t'il, ne doivent pas être négligés:
Le premier réside en la possibilité de faire du crowdsourcing.
Je m'explique: Vous évoquez le fait de pouvoir partager un album photo pour la famille et donc de mettre en place des niveaux de permission. Il faut donc qu'ils soient implémentés au niveau de votre API mais je n'ai pas trouvé à quel service ça pouvait correspondre.
Pour ce cas d'usage, un seul repository sert référence mais imaginez qu'à présent on puisse proposer un service de tags partageables entre tous pour identifier papi et mamie. Imaginez que sur une instance mutualisée chez un hébergeur, sur laquelle on stocke ses bookmarks, on veuille bénéficier de tags auto dont la pertinence est liée au nombre de clients qui ont appliqué ce même tag. Il serait dommage que chaque appli doivent réimplémenter çà au travers de requêtes massives sur l'API de chaque instance utilisateur. Il serait préférable d'offrir ce genre de service de base. Votre architecture le permettra t'elle ?
L'autre aspect est la fédération. A l'image de XMPP, on pourrait imaginer de mettre en relation plusieurs noeuds cozy afin par exemple de croiser encore plus les données ou autre exemple de partager des items de ma todolist avec d'autres utilisateurs qui ne sont pas hébergés sur le même noeud. Pour vous représenter ceci, vous pouvez vous inspirer d'OSLC qui a spécifié une architecture de bus et un protocole même s'il vise le domaine de l'ALM.
Enfin 2 petites questions.
* Il est fait mention du service /realtime. Est-ce que ceci fait référence à une implémentation des Websockets ?
* pour cozy desktop, vous avez pensé à un framework en particulier ? Electron ?
Je vais m'éloigner du sujet de la dépêche qui pose l'architecture mais j'aimerais quand même réagir sur votre stratégie.
Lorsque je lis:
Par contre, la suite à donner l'est moins. Frank défendait une approche où la majorité des personnes ont leur serveur (un RPi chez eux, ou un serveur loué à OVH, Gandi, etc.). Et dans cette approche, il est préférable de juste regrouper cozy-home, cozy-proxy et cozy-datasystem à l'intérieur d'un seul processus et d'optimiser sa consommation mémoire. Les gains sont faibles mais c'est relativement facile à mettre en place (en tout cas, bien plus facile que recoder le backend dans un autre langage).
À l'inverse, si la majorité des utilisateurs n'ont pas les compétences pour gérer leur serveur, ils vont se tourner vers des offres d'hébergement de cozy tierces. Ça peut-être l'offre beta de Cozy Cloud, bientôt celles de partenaires comme Gandi (avec qui nous avons remporté le Concours d'Innovation Numérique sur cette thématique), et plus tard, potentiellement ce que des grands groupes comme la MAIF pourront offrir à leurs clients. Dans ce cas là, il est possible d'aller beaucoup plus loin dans la réduction de la consommation de ressources (et donc faire baisser le prix d'une instance Cozy) en mutualisant les briques. Au lieu d'avoir un processus par utilisateur, on peut servir plusieurs utilisateurs avec ce même processus.
… je m'interroge quelques peu
Si on s'en tient à cet extrait, votre vision à terme n'est absolument pas l'auto-hébergement.
Vous souhaitez développer des partenariats et j'en conclus qu'il sera de plus en plus complexe de s'installer une infra pour son propre besoin sans être obligé d'en passer par un prestataire. Et vos choix architecturaux vont dans ce sens.
Je peux me tromper cependant.
Je comprend que chacun doive trouver des moyens de subsistance et je ne critique pas vos choix.
Mais il serait bien de les clarifier. Notamment sur votre page d'accueil on voit "Run your cloud at home"
Ca ne ma parait pas approprié.
Encore une fois je comprends votre position mais le minimum est d'être honnête avec vos potentiels "partenaires" (j'entends ceux qui vont rentrer dans l'aventure du LL).
Quoiqu'il en soit, me concernant je ne participerai pas si cette vision est confirmée.
D'ailleurs nous n'avons pas eu de nouvelles de Franck qui souhaitait s'exprimer.
Qu'il sache (s'il traîne par ici) en tout cas que je soutiens sa vision et que s'il souhaite relancer le projet en forkant dans cette direction, il trouvera certainement des soutiens.
[^] # Re: Réaction de Github
Posté par El Titi . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à -3.
Exemple:
Ou encore l'intégration LDAP qui je crois est réservée à l'edition pro …
Encore une fois, je comprends que chacun ait le droit de vivre de son travail. Mais expliquez ce qu'il y a de plus respectable à dire:
Si tu veux utiliser mes services hébergés chez toi, payes (tu n'auras pas les sources).sion c'est gratos pour un usage public
et
Si tu veux utiliser tous mes services chez toi payes. Pour les sources tu peux m'aider mais je conserve un avantage commercial sur toi. Toi tu reverses, moi non. Quelle différence au final avec une licence non libre sur du contenu telle que la CC-BY-NC. C'est de la pure hypocrisie.
Github étant contributeur open-source par ailleurs je me permets de répondre à l'auteur du commentaire qui semble avoir un parti pris.:
Le jour où Framasoft grandit, fédère des contributeurs et diverge du core au point que la version commerciale de Gitlab ne pourrait suivre, on en reparlerait ok ?
Bref, je maintiens: open-source washing
[^] # Re: Réaction de Github
Posté par El Titi . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à -1.
Vi enfin entre Github et un projet qui fait de l'open-source washing (Contribuez, on est des gentiiiiils et nous on garde le beurre), je vois pas la différence. Autant prendre l'original !! Et les alternatives purement open-source ne manquent pas. Un peu comme la double licence AGPL/proprio qu'un certain habitué nous ressert régulièrement.
Sinon pour ceux qui vont hurler, Github, c'est Electron, Atom, libgit2… sans double licence. Gitlab, à part récupérer les contributions des autres en gardant une marge d'avance, ils font quoi pour le libre ?
Sinon, pour les spécialistes, si on contribue en open-source à réimplémenter leur feature proprio, on risque pas de se prendre un procès ?
Accessoirement, Mattermost, leur partenaire a exactement le même modèle.
Pas que je sois contre, chacun a le droit de vivre. Sauf qu'au final c'est aussi fermé que du bon vieux closed source en terme de concurrence. Bref, sans moi !
[^] # Re: Quelle activité!
Posté par El Titi . En réponse au journal LinuxFr.org : première quinzaine de septembre 2016. Évalué à 2.
Nouveaux ou simplement actifs ?
Je suis vraiment une pôv moule accrochée à son bouchot :-(
[^] # Re: Rrrr Zzzz
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 4. Dernière modification le 20 septembre 2016 à 21:35.
Je réfléchis à cette proposition et si ça intéresse quelqu'un j'envisage une série de journaux pour présenter différents workflows avec les tenants et aboutissants de ces choix.
Nous proposons 2 workflows dans ma boîte car 2 méthodes de projets coexistent (Une itérative à la RUP et une agile basée sur SCRUM).
Ils ne sont pas outillés car le but est de ne pas proposer de choses trop compliquées.
Notre workflow agile est très semblable à ce qui est proposé ici :
http://endoflineblog.com/gitflow-considered-harmful
http://endoflineblog.com/follow-up-to-gitflow-considered-harmful
(Le 2ème post apporte des précisions utiles)
Les seules adaptations concernent:
1. Le suivi de la version en prod. On la marque par un tag qu'on déplace plutôt que par une branche
2. Les features branch:
Autant que faire se peut, on les décourage, mais à ceux qui souhaitent vraiment les mettre en oeuvre, on donne quelques consignes:
Qu'elles soient courtes et rebasées y compris sur le serveur de CI (elle sont propres à un seul developpeur). Le workflow ressemble alors à ce que décrit par Crev ici (rebase, push --force, revue éventuelle, merge --no-ff)
S'il s'agit d'epic et que l'on veut vraiment l'isoler dans une branche, il ne faut qu'il y en ait qu'une seule, que l'on réintègre depuis master à chaque commit (merge auto en CI qui casse le build si pb).
Sinon, si tu veux vraiment retrouver ton workflow à la SVN, hormis les 2 commandes de nos compères:
Je verrais bien une commande intermédiaire qui te permet d'enregistrer ton travail en local régulièrement:
et une pour le resolve après un update:
[^] # Re: Rrrr Zzzz
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
De la branche plus exactement.
C'est la raison pour laquelle j'expliquais que dans une migration git avec plusieurs composants (/comp1/trunk, /comp1/v.1.x, /comp2/trunk, …), une des solutions est de créer des branches équivalentes.
Ainsi, tu n'es pas pollué par les commits dans les autres branches, y compris celles des autres composants.
Et par ailleurs, la granularité de SVN pour un commit est par contre le dépôt (une révision par depôt). Mais grâce au fameux buble-up, il est capable de commiter des fichiers qui n'entrent pas en conflit, et tout ça de manière transactionnelle (contrairement à ce bon vieux CVS).
[^] # Re: Workflow git
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
Ce n'est vraiment pas ton genre :)
OK, plus ça dure, plus c'est dur (c'est pas comme le sexe).
Quelle est la granularité alors ?
Une branche par épique ? Y'en a que ça n'effraie pas et qui s'en sortir avec une un merge auto from upstream qui casse le build en CI pour forcer la mise à jour
Au niveau de la US, elles ont parfois du mal à tenir en moins de 4 jours surtout. si comme certains le préconisent on colle juste un gus dessus. Multiplie ça par le nb de US de l'équipe et on nage en plein merge hell.
Au niveau de la task ? Bin quel est l'intérêt d'une branche alors ? Vu que tu intègres des bouts de US, tu prends les mêmes risques de livrer une feature non finie et tu retombes dans l'effet tunnel.
Mais tu donnes quelques éléments:
La revue de code en amont. On n'as pas attendu les feature branch pour en faire. Mais c'est vrai que ca se fait en aval. La question mérite d'être discutée. De la revue de code en amont tu la fais au fil de l'eau lorsque tout le monde commites dans trunk. Tu fais du pair programming, … Suffit de pas puller comme un bourrin et fetcher avant de rebaser. Et le gugusse qui ne respecte pas les coding rules ou qui pète la CI, il va se faire repérer assez vite.
Si je trollais, je dirais que ce worklow te conviens parce que t'aimes bien joué les gros bras ;-)
Le squash pour simplifier le bisect. Si j'étais dogmatique, je dirais que ça ne devrait pas arriver souvent si t'as une batterie de tests qui te préserve de tout ça. Mais franchement 2 itérations de plus sur un bisect (surtout dans un histo linéaire), ce n’est pas le bout du monde. Et si tu bosses pas sur un UI mais sur une API, c'est encore plus simple puisque tu ne te tapes pas tout ça à la mano.
Sinon squash or not squash, c'est un autre débat et il y en a qui sont plus favorables un histo bien découpé
Indeed, mais comme je suis pragmatique.
rebase -i obligatoire avant un push, et TU+TI mockés en local.
une US ou 2 max à la fois pour toute l'équipe. On est en "scrum" les gars.
Seules les US à risque ont droit à un traitement de faveur. Feature toggling et sinon une feature branch max comme ça pas d'embrouille.
Et pis si vraiment on se ratait, les cadors git qui mergent un refactoring en 2 temps 3 mouvements adeptes du feature branch, ils sont assez frisés pour nous séparer la feature du trunk avec 2 rebase interactive et un push –force, tu ne crois pas ?
Y’en a encore qui osent refactorer dans ton équipe ?
[^] # Re: Workflow git
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
C'est là, je pense, qu'il y a beaucoup de confusions lors des échanges sur le sujet.
Pour certains une "feature branch", c'est une branche locale dans laquelle on commite plusieurs fois. On la ré agence avant de pusher, on la maintient à jour avec le master avec des pull en rebase ou en merge.
Et l'anaphore de barmic prend tout son sens: C'est un espace privé au même titre qu'un workspace SVN et pour pousser l'analogie encore plus loin, les nostalgiques de SVN peuvent se contenter de commit --amend jusqu'au moment du push. Dans mes propos, lorsque je mets en garde contre les feature branch, ce n'est pas de ça dont je parle. Au contraire, travailler dans le trunk ne dispense pas des bonnes manières à coup de rebase interactive.
Pour d'autres (c'est à ça que je fais référence) c'est un espace partagé. C'est là que plusieurs devs pushent sur un serveur, que tournent les tests d'intégrations et que des workflows d'approbation à base de code review pre-merge se mettent en place. Ce n'est pas parce que le serveur d'intégration tourne qu'on fait de la CI (j'y reviendrai). Dans ce type d'espace, on ne peut pas se permettre des rebase en permanence par rapport à master à coup de --force car réécrire l'historique en déplaçant la ref de branche distante a des conséquences sur tous les devs, si la feature n'est pas complète. C'est pour ça qu'on passe par du merge ou par un squash (https://github.com/blog/2141-squash-your-commits).
Un modèle intermédiaire vient avec les outils à la Github et les workflows à la « fork+pull request ». Ici on dispose d’un espace public mais exclusif. On publie sa branche sur le serveur, on peut y faire tourner la CI (détection de branche automatique), mais il reste privatif car dédié à un seul dev en écriture. Le dev recalé lors de la review peut donc republier ses modifs en soumettant sa pull request après un rebase. L’intégration est prise en charge par le serveur en automatique (squash+rebase ou merge, validation par un intégrateur, par quota de reviewer …). Ca convient pour du dev open source avec des contributeurs de tous horizons, y compris occasionnels, mais pour du dev en entreprise autour d’une équipe resserrée ça commence à devenir un peu lourd comme process, pour intégrer au fil de l’eau. En tout cas, si on passe par un intégrateur comme goulot d’étranglement, qu’on ne vienne pas me dire que c’est de la CI. On peut discuter des mérites, mais ce n’est pas de la CI (cf. plus bas). D’autres éditeurs (Atlassian) ont contourné le problème en évitant de passer par la case "fork" et en jouant sur les permissions au niveau des branches du repo central. Ca améliore le truc mais ça reste lourd. Le workflow que tu nous avais présenté dans un journal est dans la même veine même si plus léger (l'exlusivité est une pure convention) et indépendant d’une review ou d’un intégrateur.
Mais la conséquence de tout ça, c’est que la feature est sous la conduite d’un seul gus. Niveau granularité, ça se limite donc plutôt à une task qu’une User Story (sinon repart dans le travers des long lived) et ça rend assez caduque l’argument sur l’intégration d’une US quand elle est prête.
Concernant la CI. C’est pareil, il faut bien s’entendre sur le vocabulaire. Ce n’est pas parce que tu balances une branche sur ton serveur de CI que tu fais de la CI. Le principe de base de la CI, c’est que tout le monde intègre dans la mainline . Je vous renvoie sur un autre lien de Martin Fowler, pour savoir de quoi on cause.
Mais bon, on s’écarte du sujet initial avec l’agilité et les feature branch. Ce qui m’a fait bondir à la base, c’est qu’on en voit toujours nous ressortir le GitFlow comme la solution à tous nos problème y compris en agilité. J’ai exposé quelques arguments pour démontrer à quel point c’est faux et que chaque projet a son contexte et que le workflow universel n’existe pas. Et je suis assez satisfait de découvrir que d’autres ont émis des réserves semblables aux miennes. Je vous invite à les lire car ça rentre bien dans les détails.
[^] # Re: Workflow git
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3. Dernière modification le 17 septembre 2016 à 20:41.
Le plus simple au monde, celui qui reste compatible avec SVN et ses limitations (mais nous utilisons Git, … à bon escient):
Le Trunk Base Development.
Une branche pour les gouverner tous.
Et voici quelques ressources.
Ponctuellement, une branche de hotfix peut-être nécessaire, mais les protagonistes de Continuous Deployment la proscrivent et privilégient la mise à disposition de correctifs dans le trunk.
Il est important de dissocier les différents niveaux de maturité en agilité.
Sinon, une autre raison invoquée pour mettre en oeuvre des branches (long-lived) et que je n'avais pas évoquée concerne les migrations techniques.
On peut-être tenté de créer une branche pour migrer vers un nouveau framework ou toute autre raison technique qui affecte son architecture
Là aussi ça devient complexe à gérer. Car il faut systématiquement reporter les évolutions livrées dans la branche de prod vers la nouvelle branche de migration technique.
Une autre stratégie peut-être mise en place. Le "Branching by Abstraction". Ceci consiste à développer une couche d'abstraction dans le trunk puis faire pointer ton architecture dessus, implémenter la nouvelle et basculer dessus. L'avantage c'est que par la force des choses ton architecture devient plus évolutive et par conséquent sa qualité s'améliore (la couche d'abstraction reste).
Et pour conclure, je cite souvent Martin Fowler. Au cas où tu émettes quelques doutes sur la crédibilité du personnage, je t'invite à jeter un oeil à la liste des signataires du manifeste agile
[^] # Re: firefox
Posté par El Titi . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 1.
C'est complètement fondé. si on transpose ce raisonnement en politique. Les citoyens se désintéressent de plus en plus de la politiques. Les électeurs FN n'étant pas prêts de renoncer, la probabilité qu'on se retrouve avec Marine au pouvoir augmente.
Steve Ballmer, sauve nous des nazis de l'interface !!!!
[^] # Re: Workflow git
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 7. Dernière modification le 17 septembre 2016 à 18:47.
Ah ce fameux git-flow. Il y a tant à dire.
J'espère que vous ne bossez pas en agilité dans ta boite ? Auquel cas, ce message ne te concerne pas.
Déjà cette drôle d'idée de reporter toutes les versions de prod sur la branche master et de dédier develop à ça.
Quand un gars arrive dans une équipe pour se joindre aux forces vives, quoi de plus naturel que de bosser dans master. Si je veux connaitre le version de prod, y'a quoi de compliqué de s'appuyer sur une convention de nommage et de lister les tags avec un petit grep des familles.
Ensuite cette manie de créer une branche de release pour la recette et la maintenance. En agilité que ce soit en scrum, kanban, lean ou à fortiori en continuous deployment, on a coutume de réintégrer les demandes de corrections plus tard (sprint suivants). On ne s'amuse pas relivrer des corrections en recette ou en prod sauf cas du hotfix qui est le seul qui nécessite une branche dédié à réintégrer dans la master. Evidemment on automatise un max avec une batterie de test pour qu'une recette ne dure une éternité (test exploratoires). La branche de release avec un environnement stable pour tester est le signe avant coureur que le projet va partir en couille et que les prestataire de monkey tester vont débarquer en masse. Le cône glacé va vous refroidir.
Enfin les feature branch. Le jour où on comprendra que développer à base de feature branche, et pour aller encore plus loin de pull request avec revue online comme veulent absolument nous les refiler Atlassian, Github, Gitlab et consors qui ont tout intérêt a centraliser encore plus les workflowws autour de leurs outils pour nous revendre leur bidules, on aura fait de grands progrès.
L'agilité ça consiste à discuter au plus tôt sur les questions qui pourraient poser problème. La base de l'agilité c'est l'intégration continue. Tout ce qui y contrevient est malvenu. Relisez c'est article de Martin Fowler pour comprendre pourquoi c'est le mal:
(Je l'ai déjà posté plus haut mais là je vais appuyer l'argumentaire). Dans une feature branch,vous retardez l'intégration de vos devs et par delà la découverte de problèmes d'architecture. Vous pouvez vous réalignez régulièrement par rapport à master (merge from upstream) mais il n'en reste pas moins que vous êtes isolés de toutes les features pas encore intégrées et les autres de la vôtre. Ce n'est qu'au moment où vous intégrez que les problèmes arrivent et notamment le big bang merge, les conflits sémantiques et c'est souvent le plus mauvais moment… peu avant la fin du sprint.
Certains parlent alors du mini effet tunnel qui vous fait retomber dans les travers des méthodes traditionnelles, consustant à tout intégrer dans l'urgence et souvent au détriment de la qualité (on n'a pas le temps de refactorer nos tests là, on est à la bourre).
Au fait, reposons-nous la question: Quelle sont les raisons pour lesquelles on souhaiterait mettre en place des feature branch?
La réponse qui vient immédiatement concerne la souplesse que ça nous apporte. On peut décider d'intégrer une feature au moment d'une livraison ou de la reporter si elle n'est pas prête.
Alors déjà, première chose: Pourquoi passer systématiquement par une branche surtout en début de sprint ?
Ensuite, quel est le problème de livrer une feature incomplète … si elle n'affecte pas votre produit ?
Vous voyez poindre la solution qui permet de continuer à développer dans le trunk tout en conservant cette souplesse ? Vous l'avez tous déjà fait un jour. Supprimer un item dans un menu, ou un bouton dans un formulaire…
Ca s'appelle le feature toggling(http://martinfowler.com/bliki/FeatureToggle.html). Vous structurez votre code pour activer ou non des fonctionnalités au déploiement (http://martinfowler.com/articles/feature-toggles.html).
Ceci vous permettra même de valider ou non la pertinence d'une fonctionnalité sur un panel de clients précis ou de les comparer en environnement réel. le fameux A/B testing.
Après, il est vrai qu'une des conséquences est que ça génère de la dette technique, et qu'il faut supprimer le code d'activation lorsque la feature est intégrée ou écartée. Mais il existe des frameworks pour vous y aider.
Alors si vous voyez débarquer dans vos équipes un type qui vous vante les mérites du feature branching, et que c'est peanuts avec git et que Git flow c'est une tuerie, le même qui ne s'est jamais paluché un vrai merge des familles avec du refactoring sur le nom des packages et des classes, les changements sur les schémas de base de données, un conseil … Fuyez !!!
Toujours pas convaincus ?
Peut-être que lui y parviendra.
[^] # Re: Rrrr Zzzz
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 8.
Je ne crois pas non. La grosse différence avec SVN c'est qu'avec ce dernier, tu n'es pas empêché de committer si les changesets portent sur des fichiers disjoints. Avec git et tous les DVCS, c'est le cas. C'est inhérent au modèle distribué. Ces fameux commits de merge que l'on se doit de filtrer pour rendre l'historique plus clair ou qui justifient l'existence du rebase.
Ceci peut paraître anodin mais ça a une conséquence importante:
Avec SVN la gestion des composants est beaucoup plus souple. Un repo SVN peut accueillir des modules disjoints et les gérer comme des projets séparés de manière transparente. On n'est pas pollué par les commits des autres tout en bossant avec du trunk dev. Ceci offre beaucoup de souplesse pour faire évoluer son architecture. A un moment, on peut incorporer du code d'un autre composant ou au contraire le séparer … sans perdre l'historique.
Avec git, il faut faire des choix à priori en séparant les composants et utiliser les submodules (ou d’autres solutions équivalentes) avec toute leurs limitations et des problèmes à gérer si ces choix s’avéraient erronés ou si les besoins évoluent. L'autre solution est de dédier une branche par composant avec toute la complexité associée (convention de nommage sur les branches, …).
Je conviens que ceci est assez largement compensé par le fait que la gestion par composant peut se faire au niveau binaire, mais la granularité d'un article de configuration n'a jamais été chose simple et quelquefois la gestion de composants niveau source est incontournable.
J'ai eu à traiter une migration SVN d'un projets qui hébergeait des services. Ce fut un véritable casse-tête.
Pas convaincu ? Alors lisez pourquoi Google assume ce choix
http://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
Grosse mauvaise foi détectée.
J'ai moi aussi l'occasion d'enseigner git à « quelques » novices et même si je n'ai certainement pas tes compétences sur les entrailles du bousin, n'étant pas contributeur sur le projet, je trouve quand même ta remarque assez décalée lorsqu’il faut expliquer pourquoi on se prend un "push rejected: non-fast-forward". C'est assez cocasse d'ailleurs que pour dépatouiller tu confesses d'être obligé de faire appel à ton expertise. Ca prouve la simplicité du bousin. Pour alimenter la réflexion et sans attaque personnelle, voici un article (https://medium.com/@cscalfani/why-experts-make-bad-teachers-ccaed2df029b#.luyizwowj) qui amène à se questionner sur la manière de transmettre son savoir en tant qu’expert d’un domaine
Au titre des choses amusantes aussi, les milles manières de réécrire un historique en multipliant les commandes (rebabse -i, squash, amend, cherry-pick, reset --soft|mixed, …) mais expliquer après que par contre, ils n’ont pas été foutu de séparer le checkout d'un commit et d'un fichier, en 2 commandes distinctes ou de s'accorder sur un nom de commande pour cleaner l'index et qu'il faut en passer par un reset HEAD tellement evident … qu’un bookmark stack overflow de + pour votre collection http://stackoverflow.com/questions/19730565/how-to-remove-files-from-git-staging-area) avec un alias à la clé.
Autre truc amusant, les explications sur les dangers des commandes qui réécrivent l’historique et qu’il faut utiliser avec précaution (amend, reset , …) à cause des push. Alors oui, il y a le --force qui prévient. Oui comme tu l’expliques ailleurs, la force de Git c’est la gestion de son historique local et il faut expliquer au newbies qu’une branche locale c’est un peu comme son workspace git, c’est un espace privé. Mais en centralisé, il y a fallu créer des webhooks ou positionner des options git pour bloquer les conneries. Et on aimerait bien que git soit un peu plus prévenant en amont; comme par exemple des options pour limiter le reset sur commits non pushés. Evidemment ce n’est pas possible puisque git de base doit aussi supporter le mode décentralisé et que dans ce cas rien ne peut être anticipé (je ne sais pas qui a déjà cloné ma branche si je bouge ma ref).
Mais dans tout ça, ce que je trouve le plus savoureux, c'est de me remémorer ces trolls où certains disaient que le fait que git récupère une copie du dépôt en entier était un problème. Surtout pour un workflow centralisé en entreprise, ça n'était pas forcément un choix pertinent. On nous expliquait que grâce à son algo de compression ce n'était absolument pas un problème pour le transfert que le kernel en était une preuve.
Et maintenant, on prend conscience que des projets, ce ne sont pas que des fichiers source mais qu'on a besoin de jeu de données pour les test d'intégration, de stocker des binaires notamment dans le domaine du jeu (artworks) … et que leur place est bien dans le dépôt. Ce ne sont pas des documents Word avec lesquels on explique gentiment qu'il y a d'outres outils pour ça.
Moralité depuis:
* J'ai un collègue admin qui fait la chasse aux binaires dans les dépôts et s'amuse à les cleaner à coup de bfg (comment ça l'historique d'un projet est sacré ma bonne dame ? … Vous ne vous en servez plus, raison de service, Léon le nettoyeur va passer). En terme d’admin, on se croirait revenu au temps glorieux de Clearcase, tient.
* Git prend en charge le fait de partager un même dépôt entre plusieurs workspaces alors qu'on se moquait doucement des DVCS qui le permettaient. (Je conviens que c'est vraiment un nice to have parce qu'une recopie d'un clone en local ça coûte rien en réseau)
* Git étant surtout utilisé en centralisé (merci Github et Atlassian) et v'la tit pas qu'on nous sort du git LFS pour adresser le problème des gros fichiers. Quelle ironie du sort. A chaque checkout, on va vous expliquer qu'il faut être connecté pour récupérer la bonne version du binaire. Allez encore un petit effort et vous allez découvrir la notion de client serveur, de workspace en mode centralisé et qu'un cache pour stocker l'historique, c'est suffisant (Perforce le gère depuis le début). Ok je retire cette dernière phrase qui est de la pure provoc.
L'autre gros soucis dans le cas de workflow centralisé concerne le lock pessimiste. On a beau nous expliquer qu'un outil de gestion de version n'a pas vocation à être un outil de communication, l’argument ne passe pas. Expliquez-moi ce dont vous avez besoin, on vous expliquera comment vous en passer ! (Petit hommage à Coluche, tu nous manques). Lorsqu'on bosse avec des fichiers binaires comme des images, des fichiers qui ne proposent pas leur propre interface de merge (modèle UML, fichiers XML persistants avec une sémantique bien définies), l'argument a du mal à passer et les options --ours et --theirs du merger sont quand même un peu légères. Lorsque tu viens de te chiader l'édition d'une image et qu'un gugusse te balance une modif en même temps, y’a quand même un souci et si on vous rétorque que vous avez qu’à vous parler avant, vous pouvez aussi lui renvoyer que dans ce cas les merges ne servent à rien sur les fichiers source et il suffit de se parler et de revenir à ce bon vieux RCS. SVN avec les properties sur les types de fichiers et le svn lock le suporte au poil. Autre exemple, Talend studio (un ETL) a récemment migré de SVN vers Git pour son studio, suite forte pression client. Ils se sont retrouvés à réécrire un système de lock à part du cvs parce que les mêmes clients ne veulent pas sacrifier sur le lock pessimiste non plus.
Aujourd'hui le bilan est le suivant. Malgré ces mérites indéniables (on est tous d’accord), on se retrouve coincé avec un outil dont la vocation n'est pas le modèle centralisé. On nous explique qu'il le gère, car qui peut le plus peut le moins. Mais du coup des choses basiques qui pourraient améliorer ce workflow seraient incompatibles avec les autres modèles de workflow. Alors on voit émerger de plus en plus de solutions de contournement. Soit, mais s'il vous plait, convenez que SVN est assez adapté pour ce besoin et non, git de base n'est pas toujours aussi adéquat ni en termes de simplicité ni en termes de besoins. A côté de ça, personne ne souhaite revenir sur le confort de rajouter un remote pour bosser sur le même projet entre 2 organisations séparées ou encore la possibilité d'accueillir des contributions ponctuelles avec des pull request mais on est bien au delà d'un simple projet centralisé dans une entreprise. Quand à la possibilité de réécrire son historique avant de pusher, top de choix tue le choix. Pas toujours facile de s'accorder sur la bonne granularité du commit. Entre ceux qui visent la simplicité et veulent pouvoir cherry-picker un seul commit pour reporter une feature, ceux qui veulent pouvoir relire l'historique par petits incréments et trouvent que c'est plus simple en cas de rebase, les protagonistes de la feature branch.
Et voilà encore un nouvel animal de foire, le git series … Si ce n'est pas du cargo cult, en tout cas ça y ressemble parfois.
Pas facile de faire comprendre un newbie qui vient de découvrir les branches, les pull request vendues par les marchands de rêves à la Github/Bitbucket et qu'il veut vous en fourguer partout, que ça contrevient un des principes de bases de l'agilité: l'intégration continue. quPas facile de lui faire comprendre que les features branches n'ont rien d'agile (http://martinfowler.com/bliki/FeatureBranch.html) et venir le voir pleurer lorsqu'il a refactoré comme un porc et se trouve comme un con avec un big bang merge et qu'on doit se taper de le dépanner à coup de stratégies de merge et d'ajustement du "threshold" dans le find-renames.
Avec de grands pouvoirs, viennent de grandes responsabilités…
# Puisqu'on parle de grammaire ...
Posté par El Titi . En réponse à la dépêche Apprendre la programmation fonctionnelle avec le MOOC OCaml. Évalué à 3. Dernière modification le 15 septembre 2016 à 22:53.
Je note un petit relâchement dans le dernier paragraphe:
cette langue l'ont défendu*e* en arguant que sa grammaire ét~~é~~ait plus simple,
(que l'on a écrit pour reproduire ce groupe adverbial du français) tel qu'infér~~er~~é par le compilateur on
c'est libre, gratuit et dispens~~er~~é par des enseignants de qualité.
Sinon, très alléchant programme (à double titre) !!!
[^] # Re: firefox
Posté par El Titi . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 5.
Une grosse … fatigue ???
[^] # Re: Va falloir être soigneux les gens…
Posté par El Titi . En réponse au journal Tout simplement E P I Q U E. Évalué à 2.
C'est vrai … qu'on dirait une pub pour Audika
[^] # Re: J'ai déjà entendu ça quelque part
Posté par El Titi . En réponse au journal Tout simplement E P I Q U E. Évalué à 5.
Moi ce qui me déprime, c'est que maintenant dans le bus, les pénibles qui écoutent du rap à donf auront une vraie excuse pour leur insoutenables exactions, … ils ne peuvent pas se payer des ecouteurs.
# Complément d'information inutile
Posté par El Titi . En réponse au journal Tout simplement E P I Q U E. Évalué à 1.
… et donc indispensable
http://twog.fr/le-comptwoir-du-8-septembre-2016/
[^] # Re: J'ai déjà entendu ça quelque part
Posté par El Titi . En réponse au journal Tout simplement E P I Q U E. Évalué à 10. Dernière modification le 08 septembre 2016 à 11:11.
Regardez sur internet la définition du second degré.
Pour moi ce journal est un régal et il fait partie de la subculture DLFPienne au même titre que la bronsonisation, la journée de la procrastination (tiens d'ailleurs personne n'en a parlé cette année), les trolls systemd, …
[^] # Re: chauve qui peut
Posté par El Titi . En réponse au journal "Tant pis, ce seront nos enfants qui paieront". Évalué à 9.
Ca serait pas mal que tu ailles faire un tour au Caraibes, sur la côte et tous les endroits au soleil inabordables pour les primo-accédant avant de sortir des grossièretés de ce genre.
Quand au système par répartition, bizarrement à chaque tour de la droite on en reprend pour 3 ans…parce qu'il est déficitaire et qu'il va droit dans le mur. Soit on continue à faire des gosses pour le maintenir au risque de faire exploser la planète avec les tensions sur les ressources ou on arrête d'en faire et les générations d'actifs qui arrivent se font encore plus baiser que les précédentes.
Quand à la gauche quand on voit rewind qui défend ce système. Bizarrement, ce fameux contrat va toujours dans le même sens, pour l'équilibre: allongement de la durée de travail, précarisation du contrat de travail (ben oui faut bien les faire bosser ces jeunes cons,, de mon temps …gna gna gna), durcissement des conditions pour l'assurance chômage, …
Il est si sacro saint ce contrat intergénerationnel ? On m'a pas demandé mon avis quand je suis né.
Seuls les suédois ont eu le courage de mettre les pieds dans le plat en baissant les pensions des plus aisés, …oui Madame.
Personne n'en parle ici de peur de perdre la frange d'électeur qui mène ce monde par le bout du nez.
Les mêmes qui profitent de leur "répartition" se sont en plus gavés sur la capitalisation en achetant pour un bout de pain des belles barraques au soleil à une époque où l'inflation leur a permis d'amortir leur prêt en moins de 2. Depuis les conservateurs allemands sont passés par là et ont imposé le contrôle avec la banque centrale.
Et qu'on ne me parle pas de transmettre son patrimoine surtout à gauche… Et les orphelins, les fils de plébéiens ? Elle est où l'égalité des chances ?
Les baisés comptez vous, avec Sarko en 2017 on va vous la remettre encore plus profond.
[^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy
Posté par El Titi . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 4.
Si déjà, vous l'inscrivez sur votre backlog, je n'aurai pas perdu mon temps ;-)
[^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy
Posté par El Titi . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 2.
Si tu relis le début de ma phrase, je n'ai pas prétendu le contraire.
[^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy
Posté par El Titi . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 3.
Je n'ai pas précisément réfléchi à ça, mais je voulais d'abord attirer votre attention, afin que vous vous preniez ce besoin en compte et j'essayais de le projeter sur votre architecture.
Toutefois, voici quelques pistes de réflexion
Il faut d'abord élaborer votre système d'ACL pour en tenir compte au niveau de l'API REST mais peut-être aussi coté backend pour plus d'efficience.
Vous définissez la notion de contexte (un peu comme les cercles google) ce qui est très bien. Vous prenez en compte la notion de données cryptées. Pensez à la notion de données anonymisées à ces fins de statistiques. Ca va au delà des "metrics" puisque c'est pour un usage "métier".
Chaque utilisateur pourrait donc décider de l'utilisation de ses données en se basant par exemple sur 4 niveaux
* privé
* restreint (géré par les contextes)
* anonyme (la donnée est accédée en lecture par des traitements mais ne peut pas être associée à l'utilisateur)
* publique
Pour l'implémentation, il me semble que des processus transverses du genre de ceux mis en place par les "metrics avec des dbs dédiées(Redis ou CouchDB) pourraient convenir.
Cependant l'usage est différent puisque ces infos seraient accessibles au niveau des applications hôte. Ceci a donc un impact sur /data
De la même manière, j'imagine que dans votre architecture actuelle un développeur d'application hôte (sauf cas serverless) doit coder une partie backend s'il doit persister des infos partageables entre points d'accès. Il devrait alors pouvoir accéder à votre système d'autorisations sans passer par l'API REST sinon ça va se ressentir sur les perfs. Il devrait donc pouvoir non seulement interroger votre API bas niveau mais aussi pouvoir collecter des données anonymisées et les persister dans ces bases dédiées. Il devra certainement être en mesure aussi de publier les services associés dans un genre d'annuaire (niveau REST et plus bas)
Autre point pour la syndication.
Si j'extrapole votre archi, un système d'annuaire distribué sera mis en place et les échanges passeront par l'API REST.
Là encore un faudra peut-être prévoir des canaux basés sur des abonnements à des événements au niveau Websocket (par exemple pour calculer les indicateurs sur des données anonymisées en agrégeant plusieurs noeuds.
Enfin dernier point, prévoir une couche d'abstraction (API bas niveau incluse) permettrait de mieux cloisonner les application hôtes, voire même d'héberger à terme d'autre langages (bon ça aurait été mieux avec du Java pour cause de JVM ;-).
[^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy
Posté par El Titi . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 4.
Merci pour cette clarification … même si je crains que certains choix de design ne vous conduisent à un moment à négliger l'une des 2 cibles.
Voici donc quelques suggestions qui pourraient influencer votre architecture. Je ne suis pas assez technique pour être précis mais je comprends que cette nouvelle architecture vous permettra de scaler en multipliant les instances et même si vous vous défendez d'utiliser des microservices, vous n'êtes pas non plus dans une approche monolithique. Vous explorez une voie intermédiaire.
Il y a 2 aspects qui, me semble t'il, ne doivent pas être négligés:
Le premier réside en la possibilité de faire du crowdsourcing.
Je m'explique: Vous évoquez le fait de pouvoir partager un album photo pour la famille et donc de mettre en place des niveaux de permission. Il faut donc qu'ils soient implémentés au niveau de votre API mais je n'ai pas trouvé à quel service ça pouvait correspondre.
Pour ce cas d'usage, un seul repository sert référence mais imaginez qu'à présent on puisse proposer un service de tags partageables entre tous pour identifier papi et mamie. Imaginez que sur une instance mutualisée chez un hébergeur, sur laquelle on stocke ses bookmarks, on veuille bénéficier de tags auto dont la pertinence est liée au nombre de clients qui ont appliqué ce même tag. Il serait dommage que chaque appli doivent réimplémenter çà au travers de requêtes massives sur l'API de chaque instance utilisateur. Il serait préférable d'offrir ce genre de service de base. Votre architecture le permettra t'elle ?
L'autre aspect est la fédération. A l'image de XMPP, on pourrait imaginer de mettre en relation plusieurs noeuds cozy afin par exemple de croiser encore plus les données ou autre exemple de partager des items de ma todolist avec d'autres utilisateurs qui ne sont pas hébergés sur le même noeud. Pour vous représenter ceci, vous pouvez vous inspirer d'OSLC qui a spécifié une architecture de bus et un protocole même s'il vise le domaine de l'ALM.
Enfin 2 petites questions.
* Il est fait mention du service /realtime. Est-ce que ceci fait référence à une implémentation des Websockets ?
* pour cozy desktop, vous avez pensé à un framework en particulier ? Electron ?
[^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy
Posté par El Titi . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 9.
Je vais m'éloigner du sujet de la dépêche qui pose l'architecture mais j'aimerais quand même réagir sur votre stratégie.
Lorsque je lis:
… je m'interroge quelques peu
Si on s'en tient à cet extrait, votre vision à terme n'est absolument pas l'auto-hébergement.
Vous souhaitez développer des partenariats et j'en conclus qu'il sera de plus en plus complexe de s'installer une infra pour son propre besoin sans être obligé d'en passer par un prestataire. Et vos choix architecturaux vont dans ce sens.
Je peux me tromper cependant.
Je comprend que chacun doive trouver des moyens de subsistance et je ne critique pas vos choix.
Mais il serait bien de les clarifier. Notamment sur votre page d'accueil on voit "Run your cloud at home"
Ca ne ma parait pas approprié.
Encore une fois je comprends votre position mais le minimum est d'être honnête avec vos potentiels "partenaires" (j'entends ceux qui vont rentrer dans l'aventure du LL).
Quoiqu'il en soit, me concernant je ne participerai pas si cette vision est confirmée.
D'ailleurs nous n'avons pas eu de nouvelles de Franck qui souhaitait s'exprimer.
Qu'il sache (s'il traîne par ici) en tout cas que je soutiens sa vision et que s'il souhaite relancer le projet en forkant dans cette direction, il trouvera certainement des soutiens.
# Eh beh... ça a été long à venir...
Posté par El Titi . En réponse au journal Le noyau Linux a 25 ans. Évalué à 6.
Tout le monde comate encore ou quoi ?
Allez une petite interview du géniteur pour se mettre en bouche:
http://www.zdnet.fr/actualites/linus-torvalds-celebre-les-25-ans-de-linux-39841134.htm
[^] # Re: Roohh ce troll
Posté par El Titi . En réponse à la dépêche Appel de wallabag aux fabricants de liseuse. Évalué à 0.
Les liseuses c'est comme systemd, … c'est l'Avenir.
http://linuxfr.org/users/gnumdk/journaux/microsoft-powershell-libere#comment-1669525