C'est pour vendre ta solution que tu met "Conteneur léger" dans le titre?
Car, si je ne m'abuse, un conteneur, c'est peut-être léger quand on le compare à une VM (et on peut aisément le faire car le cas d'utilisation est de répondre aux même problématiques), mais c'est absolument pas léger dans l'absolu!
Ton conteneur contient toutes les dépendances sous-jacentes (excepté le noyau), donc il y a un grande chance que ton conteneur fasse dans les 100Mo (ordre de grandeur si il est pas fait aux petite oignons.)
Et surtout en mémoire, il prendra un peu de place, au mieux si tu as la même version des binaires dans en dehors du conteneur (et que le noyau fait de la dé-duplication de pages mémoire) et au pire, ben toutes les libs sont différentes et tu montes tout en mémoire.
Tout ça pour dire, qu'il vaut mieux ne pas utiliser "conteneur" avec "léger" ;) (sauf si tu compares avec les VMs)
Ou peut-être qu'une fois qu'on a publié sur une branche de feature/prototype/… partagée il est compliqué de réécrire l'historique et le repusher sans péter la conf de autres.
Avec un peu d'organisation, cela peut être fait. Au moins juste avant de merger…
Cela a t'il réellement un intérêt de suivre l'historique au niveau du patchset lorsque le gestionnaire de ticket fait correctement son boulot au niveau du ticket et reférence les commits asssociés.
Je pense légèrement différemment…
Pour moi, ton gestionnaire de code source doit presque (et le plus possible) se suffire à lui même.
Déjà, git est un DVCS. Donc comment tu fais pour consulter ton gestionnaire de ticket si t'es pas forcement connecté?
En plus, cela peut rendre fortement dépendant d'un gestionnaire de ticket si t'as pas bien prévu ton truc (il faut pouvoir exporter les données, le réimporter avec les même identifiants,…). Rien que si tu as fait un projet sur github, c'est pas évident.
Alors que si tu fais des beaux messages de commits (avec potentiellement des bouts de texte pris du gestionnaire de ticket), déjà tu risques de gagner du temps en évitant d'avoir à ouvrir un autre outils dans la majorité des cas, en plus tu es un peu plus indépendant (l'indispensable est dans le contrôleur de code source),…
Là où je bosse, on utilise quasiment jamais le gestionnaire de ticket lors de la recherche d'un bug dans l'historique. Si le message de commit est pas assez clair, soit on lit le code source. Si on va dans le gestionnaire de ticket, c'est qu'on a merdé notre historique.
C'est rare d'avoir des merges sans conflit. J'ai du mal à comprendre fondamentalement pourquoi c'est si compliqué.
C'est un remarque sans véritable base statistique…..
Soit tu travailles pas sur les mêmes périmètres fonctionnels et à ce moment là, c'est plutôt l'inverse, y'a (presque) jamais de merge!
Par contre si tu travailles les mêmes périmètres fonctionnels et donc sur les même fichiers de codes, ben c'est un peu normal que tu ais des problèmes de merge, non?!?
C'est marrant mais pour moi tes 2 exemples sont 2 extrêmes qui ne sont pas bons et qui montrent que beaucoup de gens n'ont pas compris la valeur de l'historique.
Pour moi, la meilleure façon de faire est entre les deux, même si je suis d'accord avec toi que cela est à adapter en fonction du contexte…
Tu as énormément de gros projets qui travaillent avec des historiques très plats car le point d'intégration est un patch (ou patch set) qui est soumis, relu et accepté. C'est par exemple le fonctionnement des projets Apache.
Je vois 2 raisons qui pourrait pousser à faire ce choix:
- ils n'ont pas encore adapté leur workflow avec ce que permettent de faire maintenant les DVCS (ou n'en utilisent pas encore)
- comme c'est un projet opensource et qu'il est plus difficile "d'imposer" une façon de faire, ils préfèrent tout squasher pour éviter d'avoir à faire du babysitting en demandant systématiquement aux contributeurs de le faire (mais ils se privent d'avoir une feature construite par étape…)
A l'inverse la plupart des projets préfèrent merger 50 commits même non travaillés. C'est aussi ce que tu vois le plus en entreprise.
Je pense que cela est dû soit à une mauvaise maitrise de git soit au fait qu'ils ont décidé de faire du travail de porc et de se foutre de l'historique (ils en ont pas encore compris la valeur)
En tout cas, dans les 2 cas, leur historique n'est surement pas optimal…
La question fondamentale derrière ça est: est-ce que les commits dans une branche ont une valeur ?
Plus que oui!!! Si tu dois retrouver un bug ou relire le code, je préfère largement lire plusieurs petits commits ayant du sens plutôt qu'un seul gros commit où ton cerveau aura beaucoup (trop?) d'informations à traiter…
Pour moi le squash n'est à utiliser que pour fusionner 2 commits qui n'auraient du être qu'un seul car tu as oublié de commiter un fichier, tu t'es aperçu que tu n'avais pas fini de résoudre le problème,…. pas pour squasher toute une branche!
PS: tu peux remplacer %C(yellow)%d%Creset par %C(auto)%d%Creset, tu auras quelque chose de plus lisible (les références aurons une couleur différente en fonction de leur type)
euuhhh….
Si tu n'as qu'un master avec des "feature branch" et que tu veuilles faire de la maintenance sur une version "extraite" d'un ancien commit de master, à ce moment là, je suppose que tu as au moins créé une branche de bug fixe pour maintenir cette version.
Donc soit :
tu me parles d'un projet d'application où vous ne supporter que la dernière version (et les bugs fixes sont dans la version d'après et c'est bien un workflow se rapprochant du "githubflow"). Ce qui arrive souvent quand on fait un petit projet opensource…
tu as créé une branche de maintenance et tu ne l'as pas indiqué dans ton message (auquel cas tu te rapproches plus du workflow "gitflow")
je ne vois pas comment tu fais de la maintenance sur une vieille version sans créer de branche…
C'est à peu prêt le "github flow", qui est parfait pour du dev web (ou des scripts de maintenance,…) où tu ne maintient qu'une version mais c'est plus problématique pour maintenir plusieurs version d'un logiciel…
Comme gogs et autre github affiche très bien les fichiers markdown, peut-être peux-tu plutôt versionner des fichiers markdown dans un répertoire nommé "wiki".
Je préfère même cette solution à un wiki car tout est versionné et dispo à travers git! (on parle bien d'un outil de gestion de dépôts git, non!?! ;) )
PS: par contre, le fait qu'il n'y ait pas de "pull request", c'est vrai que c'est bien dommage pour cette petite pépite…
Déjà, je pense que rocket n'est pas un fork de Docker (et que donc il faut corriger la dépêche) mais un projet concurrent car ils pensent que Docker a de gros défauts non vraiment corrigeables. Je conseille de lire le dernier lien donné pour en savoir plus, qui est une annonce du projet…
Ben c'est un peu normal car la poudre verte était là avant i2bp et comme la poudre verte résoudre tous les problèmes de réseau, il n'y a donc plus besoin d'avoir un codec performant ! CQFD.
Il me semble que si tu as eu besoin de cette fonctionnalité, d'autres doivent également en éprouver le besoin donc la contribuer upstream me semble une très bonne idée.
Par contre, remplacer tout simplement l'affichage existant ne me semble pas une très bonne idée.
De mon point de vue, il faudrait que tu ajoutes une option (soit dans le menu, soit dans les options d'Audacity) pour choisir le mode d'affichage.
Dans ce cas là, je ne pense pas qu'il y aurait de problème à être inclus dans le projet upstream car ça ne dérangerait personne. Le seul risque c'est que ça satisfasse plus d'utilisateurs ;)
Par contre, j'en conviens, ça demande plus de boulot…
J'adore les gens qui ne savent pas à qui ils s'adressent (et donc qui ne connait pas le background de ces personnes) et qui emploient des acronymes en espérant qu'ils soient déjà connu de tous.
En général, on explicite tout le temps un acronyme lors de la première utilisation, à moins d'être sûr que les interlocuteurs le connaisse (ce qui ne peut être vrai ici….)
Pire, j'ai acheté une boite de 25 DVD vierges un jour où je suis allé en espagne (car c'était beaucoup moins cher au moment où la techno commençait a émerger) et …j'en ai pas gravé un seul.
Au final, j'utilisais des réinscriptible pour graver des iso de distribs…
[^] # Re: Conteneur léger tel que Docker
Posté par cosmocat . En réponse au journal Comment faire une sandbox de mon système de fichier ?. Évalué à 4.
C'est pour vendre ta solution que tu met "Conteneur léger" dans le titre?
Car, si je ne m'abuse, un conteneur, c'est peut-être léger quand on le compare à une VM (et on peut aisément le faire car le cas d'utilisation est de répondre aux même problématiques), mais c'est absolument pas léger dans l'absolu!
Ton conteneur contient toutes les dépendances sous-jacentes (excepté le noyau), donc il y a un grande chance que ton conteneur fasse dans les 100Mo (ordre de grandeur si il est pas fait aux petite oignons.)
Et surtout en mémoire, il prendra un peu de place, au mieux si tu as la même version des binaires dans en dehors du conteneur (et que le noyau fait de la dé-duplication de pages mémoire) et au pire, ben toutes les libs sont différentes et tu montes tout en mémoire.
Tout ça pour dire, qu'il vaut mieux ne pas utiliser "conteneur" avec "léger" ;) (sauf si tu compares avec les VMs)
# Ceci est une...
Posté par cosmocat . En réponse au journal Colortest.it - simuler le daltonisme avec des filtres CSS SVG. Évalué à 2.
mise en abîme
[^] # Re: Plus simple
Posté par cosmocat . En réponse au journal Esod mumixam !. Évalué à 7.
En whitespace:
(Bon, c'est pas ma faute si ça passe pas sur linuxfr….)
Demain, je poste en AAAAAAAAAAAAAA!!!! ou autre
[^] # Re: Pourquoi ?
Posté par cosmocat . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 4.
Avec un peu d'organisation, cela peut être fait. Au moins juste avant de merger…
Je pense légèrement différemment…
Pour moi, ton gestionnaire de code source doit presque (et le plus possible) se suffire à lui même.
Déjà, git est un DVCS. Donc comment tu fais pour consulter ton gestionnaire de ticket si t'es pas forcement connecté?
En plus, cela peut rendre fortement dépendant d'un gestionnaire de ticket si t'as pas bien prévu ton truc (il faut pouvoir exporter les données, le réimporter avec les même identifiants,…). Rien que si tu as fait un projet sur github, c'est pas évident.
Alors que si tu fais des beaux messages de commits (avec potentiellement des bouts de texte pris du gestionnaire de ticket), déjà tu risques de gagner du temps en évitant d'avoir à ouvrir un autre outils dans la majorité des cas, en plus tu es un peu plus indépendant (l'indispensable est dans le contrôleur de code source),…
Là où je bosse, on utilise quasiment jamais le gestionnaire de ticket lors de la recherche d'un bug dans l'historique. Si le message de commit est pas assez clair, soit on lit le code source. Si on va dans le gestionnaire de ticket, c'est qu'on a merdé notre historique.
[^] # Re: Complexe
Posté par cosmocat . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 2.
C'est un remarque sans véritable base statistique…..
Soit tu travailles pas sur les mêmes périmètres fonctionnels et à ce moment là, c'est plutôt l'inverse, y'a (presque) jamais de merge!
Par contre si tu travailles les mêmes périmètres fonctionnels et donc sur les même fichiers de codes, ben c'est un peu normal que tu ais des problèmes de merge, non?!?
[^] # Re: Pourquoi ?
Posté par cosmocat . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 2.
C'est marrant mais pour moi tes 2 exemples sont 2 extrêmes qui ne sont pas bons et qui montrent que beaucoup de gens n'ont pas compris la valeur de l'historique.
Pour moi, la meilleure façon de faire est entre les deux, même si je suis d'accord avec toi que cela est à adapter en fonction du contexte…
Je vois 2 raisons qui pourrait pousser à faire ce choix:
- ils n'ont pas encore adapté leur workflow avec ce que permettent de faire maintenant les DVCS (ou n'en utilisent pas encore)
- comme c'est un projet opensource et qu'il est plus difficile "d'imposer" une façon de faire, ils préfèrent tout squasher pour éviter d'avoir à faire du babysitting en demandant systématiquement aux contributeurs de le faire (mais ils se privent d'avoir une feature construite par étape…)
Je pense que cela est dû soit à une mauvaise maitrise de git soit au fait qu'ils ont décidé de faire du travail de porc et de se foutre de l'historique (ils en ont pas encore compris la valeur)
En tout cas, dans les 2 cas, leur historique n'est surement pas optimal…
[^] # Re: Pourquoi ?
Posté par cosmocat . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 4.
Plus que oui!!! Si tu dois retrouver un bug ou relire le code, je préfère largement lire plusieurs petits commits ayant du sens plutôt qu'un seul gros commit où ton cerveau aura beaucoup (trop?) d'informations à traiter…
Pour moi le squash n'est à utiliser que pour fusionner 2 commits qui n'auraient du être qu'un seul car tu as oublié de commiter un fichier, tu t'es aperçu que tu n'avais pas fini de résoudre le problème,…. pas pour squasher toute une branche!
PS: tu peux remplacer
%C(yellow)%d%Cresetpar%C(auto)%d%Creset, tu auras quelque chose de plus lisible (les références aurons une couleur différente en fonction de leur type)[^] # Re: Mon workflow
Posté par cosmocat . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 3.
euuhhh….
Si tu n'as qu'un
masteravec des "feature branch" et que tu veuilles faire de la maintenance sur une version "extraite" d'un ancien commit demaster, à ce moment là, je suppose que tu as au moins créé une branche de bug fixe pour maintenir cette version.Donc soit :
[^] # Re: Mon workflow
Posté par cosmocat . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 1.
C'est à peu prêt le "github flow", qui est parfait pour du dev web (ou des scripts de maintenance,…) où tu ne maintient qu'une version mais c'est plus problématique pour maintenir plusieurs version d'un logiciel…
[^] # Re: Y'a plus simple
Posté par cosmocat . En réponse au journal GitLab, mais encore ?. Évalué à 3.
ouais, sous github c'est la même chose. Mais du coup, tu as 2 dépôts à maintenir pour chaque projet.
En plus, là, tu as ton wiki synchronisé avec tes sources, ce qui me parait un avantage….
[^] # Re: Y'a plus simple
Posté par cosmocat . En réponse au journal GitLab, mais encore ?. Évalué à 3.
Comme gogs et autre github affiche très bien les fichiers markdown, peut-être peux-tu plutôt versionner des fichiers markdown dans un répertoire nommé "wiki".
Je préfère même cette solution à un wiki car tout est versionné et dispo à travers git! (on parle bien d'un outil de gestion de dépôts git, non!?! ;) )
PS: par contre, le fait qu'il n'y ait pas de "pull request", c'est vrai que c'est bien dommage pour cette petite pépite…
[^] # Re: Dépêche pas très claire...
Posté par cosmocat . En réponse à la dépêche Rocket, ou pourquoi l'équipe de CoreOS lance une alternative à Docker. Évalué à 9.
Déjà, je pense que rocket n'est pas un fork de Docker (et que donc il faut corriger la dépêche) mais un projet concurrent car ils pensent que Docker a de gros défauts non vraiment corrigeables. Je conseille de lire le dernier lien donné pour en savoir plus, qui est une annonce du projet…
[^] # Re: Inadmissible
Posté par cosmocat . En réponse au journal HEVC/VP9 : x265 vs libvpx. Évalué à 5.
Ben c'est un peu normal car la poudre verte était là avant i2bp et comme la poudre verte résoudre tous les problèmes de réseau, il n'y a donc plus besoin d'avoir un codec performant ! CQFD.
# Contribution
Posté par cosmocat . En réponse à la dépêche Modeste contribution à Audacity sur l'affichage des temps. Évalué à 10.
Il me semble que si tu as eu besoin de cette fonctionnalité, d'autres doivent également en éprouver le besoin donc la contribuer upstream me semble une très bonne idée.
Par contre, remplacer tout simplement l'affichage existant ne me semble pas une très bonne idée.
De mon point de vue, il faudrait que tu ajoutes une option (soit dans le menu, soit dans les options d'Audacity) pour choisir le mode d'affichage.
Dans ce cas là, je ne pense pas qu'il y aurait de problème à être inclus dans le projet upstream car ça ne dérangerait personne. Le seul risque c'est que ça satisfasse plus d'utilisateurs ;)
Par contre, j'en conviens, ça demande plus de boulot…
[^] # Re: Ne vas pas trop vite !
Posté par cosmocat . En réponse au journal Sécurité de l'open source Vs closed source: MS14-066. Évalué à -9. Dernière modification le 17 novembre 2014 à 14:43.
J'adore les gens qui ne savent pas à qui ils s'adressent (et donc qui ne connait pas le background de ces personnes) et qui emploient des acronymes en espérant qu'ils soient déjà connu de tous.
En général, on explicite tout le temps un acronyme lors de la première utilisation, à moins d'être sûr que les interlocuteurs le connaisse (ce qui ne peut être vrai ici….)
CVE : Common Vulnerabilities and Exposures
[^] # Re: merci
Posté par cosmocat . En réponse au journal Alexandre Grothendieck est bronsonisé. Évalué à 4.
Également celui de libération
[^] # Re: Autre lien pour suivi en direct
Posté par cosmocat . En réponse au journal Pose toi Philae ! . Évalué à 10.
https://twitter.com/JRehling/status/532578871494070272
Détail du tweet:
-Fox: "Why did America waste money landing on a comet?"
-Scientist: "This is a European mission."
-Fox: "Why didn't America get there first?"
[^] # Re: Bonne nouvelle ?
Posté par cosmocat . En réponse au journal Microsoft libère les sources du cœur de .NET sur github, et ouvre son processus de développement. Évalué à 4.
Ah bon! J'ai toujours entendu dire que IntelliJ se débrouillait beaucoup mieux qu'Eclipse (un peu à la ramasse) en ce qui concerne la complétion…
Disclamer: Utilisateur d'aucune des 2 solutions, donc ce n'est pas un lancé de troll (déguisé)….
[^] # Re: Autre lien pour suivi en direct
Posté par cosmocat . En réponse au journal Pose toi Philae ! . Évalué à 4.
C'est un xkcd "live" qui évolue en fonction des infos disponibles (et Philae est positionnée en "temps réel" dans le dessin)
[^] # Re: Le temps passe
Posté par cosmocat . En réponse au journal K3b, le logiciel de gravure de KDE est toujours en vie. Évalué à 3.
Pire, j'ai acheté une boite de 25 DVD vierges un jour où je suis allé en espagne (car c'était beaucoup moins cher au moment où la techno commençait a émerger) et …j'en ai pas gravé un seul.
Au final, j'utilisais des réinscriptible pour graver des iso de distribs…
# Comet?
Posté par cosmocat . En réponse à la dépêche Meteor 1.0. Évalué à 3.
ça a à voir quelque chose avec Comet?
Parce que ça me semble très proche… (outre le jeu de mot dans le nom)
[^] # Re: Un peu de lecture sur le sujet
Posté par cosmocat . En réponse à la dépêche L’Académie des sciences française prétend vouloir l’ouverture des publications scientifiques. Évalué à 2.
Également un article intéressant qui n'est pas sur le même sujet (travaux scientifiques inutiles car pas de bonne qualité) mais dont les conclusions sont similaires (il faut repenser le système de publication et rendre tous les jeux de données publiques) :
http://passeurdesciences.blog.lemonde.fr/2014/10/29/un-chercheur-denonce-linutilite-de-nombreux-travaux-scientifiques
# Un retour d'expérience...
Posté par cosmocat . En réponse au message Docker. Évalué à 3.
avec une partie des réponses à ta question…
http://blog.iron.io/2014/10/docker-in-production-what-weve-learned.html
# Oubli ?
Posté par cosmocat . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 5.
Tu as oublié de parler de personnes qui essaient de relancer le vote pour le système d'init de debian: http://lwn.net/Articles/616571/rss
# Complément d'informations
Posté par cosmocat . En réponse au journal Docker pour Windows Server. Évalué à 2.
Ce post sur le blog de docker apporte des infos intéressantes:
https://blog.docker.com/2014/10/docker-microsoft-partner-distributed-applications/
En tout cas, j'attendais ça avec impatience…