CrEv a écrit 4577 commentaires

Ha ok, j'avais pas pensé à cette histoire de refspec. C'est vrai que ça peut être une solution.
Pour le moment il n'y a pas plusieurs master donc pas de problème pour ça.

Merci pour tous ces détails ;-)

Pour en rajouter sur le Branch by abstraction il y a aussi toute une série d'articles de qualité chez Paul Hammant : http://paulhammant.com/categories.html#branch_by_abstraction,_etc

Et d'ailleurs ça amène la discussion (on rejoint aussi ce que dit ckyl plus haut en parlant d'historique très plat) sur le terrain du Trunk based development.

Pour certains projets c'est réellement ce que je tenterais. Par exemple pour des projets web aujourd'hui je ferais plutôt du TBD (qui peut se faire aussi avec des branches à très courte durée de vie + merge squash) avec du Feature flipping (ou Branch by Abstraction). Au final je trouve que ça offre une réponse intéressante à des questions complexes comme "comment effectuer des changements profond sans diverger trop longtemps" (ex changement du moteur de stockage d'une appli). Mais pour que ce soit intéressant il faut CI avec déploiement continu. C'est un workflow vraiment agréable.

Dans l'idéal j'appliquerais ça à notre projet. Mais c'est juste pas possible. Pour avoir un déploiement continu il faut une procédure automatique qui permet de valider un code. Et donc un ensemble de tests avec une couverture et une fiabilité suffisante pour garantir le bon fonctionnement. Déjà là on tombe dans un cas tordu, si je développe une appli web ou un drone la fiabilité suffisante n'a pas le même sens. Et là je suis dans le deuxième. Ensuite la couverture aujourd'hui n'est pas suffisante car on s'interface avec du matériel. Et aujourd'hui nous n'avons pas d'autres solutions que de valider manuellement le comportement en réel (nous avons déjà eu des cas où tout fonctionnait bien en simulation mais pas en croisé sur des problématiques de temps réel par exemple).
Donc on introduit de la latence et on ne peut valider automatiquement.

Il pourrait à la rigueur y avoir des variations.
Par exemple un fonctionnement style pull request avec validation de toutes les branches indépendamment. Dans ce cas une fois de retour de tests, il suffit d'accepter ce qui passe. Mais (il y a toujours un mais) on ne teste jamais l'intégration de multiples développements (l'intérêt de notre branche d'intégration) et les tests deviennent encore plus fastidieux.

je ne me vois pas désactivé un feature en le supprimant du master, cela me semble en effet totalement bizarre comme pratique.

Pourquoi ?
Ça veut dire que tu conserves du code mort, non ?
Il existe des domaines où c'est juste interdit d'avoir du code mort (pour pouvoir certifier dans l'aviation par exemple).

des décennies de normalisation de la conception logiciel ?

cad ? (juste pour être certains de comprendre ce qu'il y a derrière ;-))

Indefero supporte mercurial

Ça et le fait de pouvoir "valider" le code sans latence.
C'est ce genre de truc qu'on utilise lorsqu'on bosse sur des projets web / natifs avec une bonne couverture de tests et un bonne CI. En général branches + rebase -i (vive autosquash aussi, ex https://coderwall.com/p/hh-4ea) + pull request
Le résultat est pas mal et assez fluide, mais limité à un master.

Intéressant comme approche.

Par contre ça veut dire que vous gardez en plus toutes les branches ? Ça devient pas un peu vite le bordel ?
On bosse par itération de deux semaines, on doit créer genre 5 à 10 branches par itération. Si on prend un peu de recul ça va vite devenir ingérable, non ?

Mais en tout cas je garde l'idée dans un coin.

Voui, c'est une possibilité. Mais c'est intéressant surtout si on gère des versions, des branches de maintenances, etc (j'en ai parlé un peu dans la description complète de notre workflow).

A noter que c'est aussi dispo pour Mercurial : hgflow et que les deux sont accessibles dans le pas libre SourceTree.

Ha oui, c'est vrai. Mais d'un côté on est sur quelque chose de bien plus gros. Là c'est une équipe de moins de 10 devs. Et assez inhabituel pour moi de bosser de la sorte. La seule fois c'était dans un autre taff où c'était la seule solution pour éviter que certains poussent leurs modifs n'importe comment sans jamais les tester :/

il y a le noyau Linux, qui est maintenu sous la forme de tas de branches et de fusions, et visiblement ça marche

Oui et non. Oui en apparence, dans le détail il y a des règles qui sont entre autre "ne te fusionne pas avec l'upstream n'importe quand / comment" (http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html)

À mon avis, il serait plus utile de cesser de faire la grimace devant un historique qui présente des branches multiples, et considérer cela comme un fait sans conséquences.

Ça c'est vrai, à une condition : que tu ne cherches jamais à relire ton historique. Un gestionnaire de source c'est un outil au quotidien pour partager le boulot mais c'est aussi un historique qui se doit d'être clair et compréhensible. Il m'est déjà arrivé de passer 1,5 jour uniquement à chercher le commit ayant entrainé une régression. L'historique contenait tellement de merges dans tous les sens que c'en était illisible et qu'un bisect était horrible.
Et malheureusement revenir dans l'historique est une pratique relativement fréquente, surtout dans notre cas particulier qui est de ne pas pouvoir valider à 100% un code sans "prendre la voiture un jour de beau temps, faire quelques dizaines de bornes, tester sur du matériel réel, rentrer". Ce qui introduit de la latence. Et comme il y a latence on bosse déjà sur la suite et, si le point en test n'est pas passé, alors on reviens dessus pour le corriger.

Maintenant s'il y a moyen d'avoir un historique lisible avec des branches à tout vas, je veux bien ;-)

Il n'y a pas vraiment de moyen d'échapper à l'utilisation de branches de maintenances. […]

Attention, je ne dis pas qu'il n'y en aura jamais. Juste que là maintenant il n'y en a pas. master est notre branche stable et en quelque sorte il n'y a pas de maintenance à faire puisqu'on est en plein dans une phase de dev et non d'exploitation.

Et même sans ça, en vrai si il est possible de se passer de ces branches, mais c'est des choix différents qui sont d'avoir quelque chose qui s'approche plus de la "rolling release".

Oué enfin avec cette logique il n'aurait jamais du essayer de mettre à jour sa distrib si elle marchait bien.

Il existe une version pour Mac. Le portage pour linux serait peut être possible à partir de là

Ça serait plutôt surprenant, à mon avis la version Mac utilise plutôt les libs graphiques Mac.

Je crois oui ;-)
D'après ce que je sais il y étaient déjà et une personne de chez eux avait beaucoup poussé pour l'ajout de la programmation par contrat dans Ada 2012. Mais ils n'y sont plus et je ne sais pas pourquoi.

Bon au final pour le moment je ne fais pas d'Ada mais j'embarque du C++ sur des drones, ce qui est déjà cool (et change du web…). Mais la version Ada suivra plus tard.

oué enfin le truc c'est
- ça serait cool que github libère son code
- meu non ça sert à rien du tout
- ben si pour pouvoir l 'installer chez soit ex github enterprise (ou gitlab hein)

Après peut-être que tu crois qu'il n'y a aucun lien entre github.com et github enterprise mais j'ai comme un doute…

Ça tombe bien, c'est à toi que je pensais pour une adhésion :)
je crois que je sais où tu bosses maintenant :D

héhé :-) Bon en même temps je ne suis pas le seul de la boite sur linuxfr…

Merci pour la news.
Je vais voir pour remotiver des gens dans ma boite, faut dire qu'on est déjà dans les membres (mais je crois que personne n'est allé aux dernières réunions)

C'est vrai que ce serait une bonne chose que le groupe continue à exister.

Vous êtes totalement ridicule et montrez votre incompétence manifeste sur le développement d'un service comme Github.

-_-'

Le "site" github n'est qu'une facade, la partie visible de l'iceberg et franchement libérer son code source ne servirait à personne, principalement parce l'appli est fortement liée à une multitude de services et outils sous-jacent, taillés, configurés, organisés, architecturés, pour supporter chaque jour des millions de requêtes http, des milliers d’exécutions de jobs en tout genre etc…

C'est bien joli tout ça, mais tu as tort. Pour le coup c'est toi qui ne voit qu'une partie de github. Parce que github c'est aussi Github enterprise que tu peux héberger chez toi, sur ton infrastructure (et maintenant aussi su AWS)
Github est aussi fait pour tourner sur des serveurs "perso" et non uniquement sur l'infra "grand public" de github.

Bref, Github, c'est déjà pas mal libre, et c'est déjà bien suffisant

Snif

car le reste n'aurait strictement aucun intérêt pour personne

Ben non, et là tu te gaufres, si c'était le cas personne n'utiliserais github enterprise.

A mon avis tu as quand même loupé un pan entier de Github.

Les touches de fonctions sont vitales pour quiconque fait un minimum de programmation

Soit je ne code pas assez o_O soit il y a comme un problème avec ce que tu racontes ;-)

D'ailleurs je n'ai qu des claviers où les touches de fonctions sont désactivées par défaut. J'utilise beaucoup plus souvent les touches de lecture de ma musique ou du volume que les touches de fonctions qui ne me servent presque jamais.

Genre au lieu de F4 j'utilise CTRL/cmd L, CTRL K d'ailleurs sous firefox pour le champ de recherche. CTRL/cmd R pour rafraichir. Etc.
Idem pour impr écran & co.

Les touches de navigation je ne m'en sert jamais (je n'en ai pas d'ailleurs) je fais tout avec des combinaisons sur les flèches, je trouve ça plus pratique car cela permet de varier la "vitesse" de navigation sans bouger.

\ ? Pourtant c'est facile, c'est alt + shift + / et ça tombe sous la main naturellement.

Comme quoi, on peut développer sans jamais utiliser les touches de fonction et les virer ne poserait en réalité pas beaucoup de problème à part prendre d'autres habitudes.

note quand même que tu liste que des choses que Rust ne sait pas faire par rapport à Ada

Ben oui, puisque certains disent que Rust marche sur le même segment que Ada je regardais si Rust permettait ce que Ada permet. Savoir ce que Rust peut faire de plus c'est encore autre chose.

Et la conclusion c'est que Rust n'est pas sur le même segment que Ada.

Voui, bien vu, en fait je ne l'écris jamais donc j'ai supposé, j'aurais du vérifier.
Dans tous les cas on ne retourne pas la valeur, c'était surtout ça ;-)

Amusant que tu répondes ça

Pas tant que ça.
Autant des devs ruby qui ne comprennent pas { |plop| … } j'en connais pas, autant des devs c++ qui ne comprennent pas les lambda j'en connais.
C'est triste. (bon par contre moi j'aime bien les lambdas en C++ et je les utilises autant qu'en ruby j'utilise ce qui est possible)

Cf la réponse de michel à propos de nommer le prédicat.

Oui mais ça veut dire qu'il faut sortir le IsEvent ailleurs donc au final on ne fait que déplacer le problème.
Et reste qu'on perd l'idée de sélection, il faut l'extraire par la compréhension du code.

en pratique j'écrirais {|value| value if value.even?} qui me parait plus lisible

En fait dans l'exemple que j'ai donné on retourne un booléen qui indique si on prend ou non la valeur.
Sans le return implicit ça donne juste { |value| return value.even? }
On est dans le cas d'une sélection où on indique si on doit sélectionner ou non la valeur et pas renvoyer la valeur (ce qui a un sens différent au final).

Cette structure est triviale en C++. Et elle se comprend très bien telle qu’elle (au moins aussi bien que ta structure ruby), et est concise.

Oué, faut pas déconner quand même.
C'est pas trivial vu le nombre de dev c++ qui ne comprennent pas les lambda, et c'est pas concis non plus.
Et c'est pas aussi expressif (even? l'est beaucoup plus)

si tu avais un each oui, mais vu que tu as un select tu dis quand même clairement que tu réalises une sélection

Honnêtement je suis moins habitué aux x for x in mais c'est parce que je fais pas beaucoup de python. Mais ça reste concis et lisible.

Par contre, je note deux grosses différences qui me font préférer la version ruby :

• avoir x.even? au lieu de x % 2 == 0 est pour moi plus clair. Dans un cas on dit clairement ce qu'on souhaite, quel est le but (un pair) dans l'autre on donne une formule et on en déduit qu'on veut un pair
• avoir myArray.select au lieu de x for x in myArray if Idem, dans un cas on dit ce qu'on veut (sélectionner) dans l'autre on doit le déduire (si je met un test c'est que je ne les prend pas tous donc je fais une sélection)

En gros dans un cas on dit ce qu'on fait, dans l'autre on décrit des actions et on en déduit une volonté.