Reprise du message précédent :

Tu as dû te battre contre la terre entière pour convaincre le management que s'était nécessaire ?

Je sais pas trop quoi répondre, je suis toujours assez belligérant au boulot de manière générale.  
je sais pas trop ce qu'en pense 0x90 de cette question.

teh fuck

http://nraynaud.github.io/webgcode/
'tain il me faut un designer

Ouais c'est un des derniers trolls, entre l'austérité et le retour du SMIC jeune : la suppression des départements et des régions

mon pote tu peux commencer à apprendre "Les prisons de Nantes"
 
La Bretagne, de Bures-sur-Yvette à Ouessant

Nan mais y a de la bonne idée, mais proposez ça comme jeu ça me paraît bof bof alors qu'une analyse intéressante aurait été bienvenu. Y a trop de département, et sûrement trop de régions.  
Nantes en Bretagne !! Certes, mais pour une anecdote historique comme ça, y'a plein de complexité socio économique derrière.
 
 Si c est décidé rapidement comme le reste, ça promet

Ça me va, j ai toujours été pour. Darlan et Pétain sont pas les meilleurs références pour justifier ce découpage

Sans les parasites c'est 50000 agents de pôle emploi au chômage
 
ah mais du coup ils seraient inscrits à pôle emploi et il faudrait embaucher des agents
 

lorill> si tu passes par ici, je sais pas si tu connais http://en.wikipedia.org/wiki/The_Bones_of_All_Men mais je pense que ca te plairait.
 curieux melange mais ca marche bien. (dispo sur spotify)

 
L'anglais

Fridredi  

 
http://extensiblewebmanifesto.org/

 
nope, puisque la PR était le point de départ pour faire la revue de code.

http://www.therestartpage.com/
 
Y'a pas d'Atari !

 
J'ai hésité, on sait jamais

Ca existait pas en TOS 1.xx

je cherche pas un manifeste, je cherche à faire des flèches

webG

et Control-Alt-Delete et Control-Alt-Shift droit-Delete

Je suppose qu'ils ont 2 repos: un avec des push-requests pour la CI et un pour les vrais releases. C'est pas idiot.
 
Chez nous aussi, on commite d'abord et on décide après. Y a tous les outils qu'il faut pour lancer les tests à l'avance sur toutes sortes de plateformes (et faire des code-reviews optionnelles), mais c'est seulement lors du commit qu'on valide tous les environnements. Par contre, la règle c'est: tout doit toujours être vert. Tout test en erreur, toute compil foireuse doit immédiatement être corrigée. Cette souplesse nous fait gagner beaucoup de temps et ne nous baisse pas la qualité. C'est même le contraire puisqu'on fait la plupart de nos code-review sur le vrai code et le vrai résultat des tests plutôt que sur du boulot pas forcément fini à 100%.

Je vois pas le rapport (ou l'incompatibilité) avec un bot d'integ, si ce n'est qu'il évite d'avoir des tests en erreur en amont.

Ouais dans tous les cas, ils n'ont qu'à refaire leur site : theloadingscreen.com ou que sais-je...

on utilise GH. Toute fonctionnalité est intégrée à travers une PR.

Le dev code dans sa branche, quand il est prêt, il fait une PR. Ca déclenche le CI server qui va lancer tous les tests et marquer la branche avec le résultat des tests. Tant que c'est pas vert, personne d'autre ne regarde le code. Quand c'est vert, revue de code et merge si ok.

Si le bot merge automatiquement, je ne sais pas comment/quand tu fais une revue de code dans ce cas.

Le bot d'integ, tu lui mets les conditions que tu veux. Genre que la PR a été revue et acceptée

 
C'est quel genre de service qui propose ça ?

Service je sais pas, mais c'est comme ça que fonctionne le projet rust, le seul committer ('fin le seul committer normal) c'est bors, un bot qui scanne les PR, regardes si elles sont été revues (acceptées), si ça merge sans conflit et si les tests passent. Si tout est bon, il merge.

En amont de quoi ? Soi ton CI représente strictement le repo officiel (et donc tu as le besoin de tester que tout ce qui rentre dedans marche, et tu dois gérer les cas où ça ne marche pas).
Son ton CI ne représente pas ta mainline officielle. Tu as donc un souci de couverture réelle: ce qui est vu par le CI n'est peut-être pas ce qui a été mergé en vrai.

Option 3, le CI merge la PR dans le master, check qu'il n'y a pas de conflit et teste en post-merge.Si ça foire, il discard et il ne push pas sur le repo officiel, si ça passe il pousse sur le repo.

Ce qui est vu par le CI est litéralement ce qui est mergé en vrai.

Ah je vois, ça implique donc que strictement aucun commit n'aille directement vers la mainline officielle.  
 
Ca marche bien de façon distribuée (e.g.: progagation de la PR sur d'autres machines slaves) ?  
 
Techniquement, c'est impossible pour nous avec Jenkins+SVN. Le truc le plus approchant, ça serait de faire un revert en cas de commit merdeux. Parce que oui, on ne peut pas proposer de patch binaires sous svn alors que certains de nos fichiers sont binaires. On est donc olbigés de passer par le repo, et hors de question de créer une branche par commit.
 
edit: mais de toutes façons, on A fortement besoin d'accepter certaines tolérances (tel ou tel test en erreur temporairement, tel code à corriger sous un environnement exotique plus tard, le code-reviewer est en RTT, etc.)

Pas nécessairement, mais ça ralentit le bot si c'est pas le cas (il tente de ff/push, ça lui dit qu'il y a un conflit, faut recommencer) et c'est pas nécessaire: au lieu de donner le commit bit tu donnes un droit d'auto-review par exemple. Et ça évite le "je fixe juste une ligne, pas besoin de faire tourner les tests ça risque rien" (pas de bol, tout est rouge)

On doit pouvoir distribuer le build comme d'hab, par contre je pense que ça sérialise complètement les runs, si le run actuel est pushé il invalide des runs parallèles. D'un autre côté le bot peut bosser 24/7

oui ça part clairement du principe que tu peux proposer des merges sans polluer le repo final, avec svn c'est probablement pas une option.

 
Parce qu'à la fin de la revue de code, clicker sur le bouton merge de GH, ca semble pas moins automatique ce que je décrivais

Stuff computers are good at: pointless repetitive crap.

En fait, si, et d'ailleurs on le fait en phase amont, mais qu'avec du texte.  
 
Malheureusement, il n'existe pas d'outil en ligne de commande capable de merger plusieurs révisions ensemble comme sait le faire Tortoise Merge. Genre, tu soumis un diff entre ton code et r5, mais le trunk est en r6. TortoiseMerge sait faire un 3-way merge entre r5, ton code et r6. Mais les outils en ligne de commande ne savent pas faire quand le patch est externe et entrent donc rapidement en conflit.  
 
Et puis le format de svn diff est un format bâtard qui change à chaque version ou presque: pour intégrer ça à Jenkins, j'ai du écrire du script python pour nettoyer les fichiers, créer les arborescences, corriger les properties svn, etc.

Sans les props, t'avais l'option --diff-cmd

Et maintenant t'as --git aussi, pour le format étendu de git Et --patch-compatible, qui devrait être compatible patch(1)

 
Enfin il faut bien que l'humain dise au bot qu'il valide la revue de code..

Oui enfin, l'une de nos plateformes, c'est du svn 1.5 sous solaris 10, et  j'ai quasiment que des cliqueurs dans mon équipe. On réussit d'ailleurs le petit miracle de livrer&tester 5 plateformes unix toutes les 2 semaines depuis 3 ans sans qu'aucun de mes collègues n'ait jamais à se connecter sur une de ces machines. La plupart seraient même incapables de dire qu'ils font du g++, du clang ou du Solaris Studio.
 
On avait testé ça récemment (car ça n'existait pas quand j'ai créé mon système):
  https://wiki.jenkins-ci.org/display [...] ter+Plugin
Mais ce n'était pas parfait, je ne me souviens plus quels étaient les soucis, mais je crois que c'était en cas de conflit que c'était peu expressif.
 
On devrait peut-être tester un truc comme ça:
  https://wiki.jenkins-ci.org/display [...] rge+Plugin
 
Le souci numero 1, c'est que toute l'intégration continue est basée sur un mirror SVN read-only. Le repo central est aux US, est il n'est pas assez stable à mon goût. Du coup, il faut customiser à outrance tous nos workflows, car c'est rare de faire un check-out depuis un repo et un commit dans un autre repo.

Je suis en arrêt maladie pour 3 semaines, du coup je m'occupe un peu: je regarde House of Cards. Ca démarre bien la saison 2.
Attention, spoiler.