cosmocat a écrit 2112 commentaires

Pourquoi ?

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…

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….

J'avoue qu'un petit Wiki ne serait pas de trop

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…

même la poudre verte est plus connue (à raison).

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….)

CVE : Common Vulnerabilities and Exposures

Également celui de libération

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?"

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é)….

C'est un xkcd "live" qui évolue en fonction des infos disponibles (et Philae est positionnée en "temps réel" dans le dessin)

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…

ça a à voir quelque chose avec Comet?

Parce que ça me semble très proche… (outre le jeu de mot dans le nom)

É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

avec une partie des réponses à ta question…
http://blog.iron.io/2014/10/docker-in-production-what-weve-learned.html

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

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…

http://linux.slashdot.org/story/14/10/10/199258/nvidia-presents-plans-to-support-mir-and-wayland-on-linux

Y'a un (bon) post sur Gnome & Wayland dans fedora 21 qui explique bien ce qu'est Wayland et les limitations de ce genre pas encore supportées.

Si je ne m'abuse (je dis peut-être un connerie car je n'ai également pas tout compris), il reste quand même des usages actuels qui ne sont pas possible actuellement avec wayland et auxquels il faudra trouver une solution pour pouvoir se passer intégralement de X. J'ai cru comprendre que les raccourcis globaux que pourraient définir une application ne sont pour le moment pas possible. Et peut-être également la capture d'écran…

Quelqu'un pour confirmer/infirmer?

Non, l'utilisation du noyau NT pour l'OS grand public (et non pas destiné aux entreprises) s'est faite avec XP.

Je sais bien, ce que je critique, ou plutôt ce dont je m'amuse, c'est du manque d'homogénéité entre ces noms marketing.

C'est marrant. Tu regardes d'un point de vue de linuxiens ou chaque distrib a sa règle pour choisir le nom de sa prochaine version pour juger ce que font les autres….

Moi, je trouve qu'il y a une certaine logique. Ils sont uniquement "drivé" par le marketing. Ils veulent vendre leur produit. Et pour cela, ils suivent 2 règles (au lieu d'une seule pour les distib linux --donc ça doit être mieux! --) :

1. Prendre la version suivante dans la façon actuelle de nommer les versions (pour montrer que c'est plus mieux).
2. Trouver une autre manière totalement différente de nommer de façon à montrer à l'utilisateur que c'est totalement nouveau et différent (pour susciter le désir d'acheter)… lorsque la précédente version a fait un gros bide.

Pourquoi continuer à râler contre Systemd quand il suffit de ne pas l'utiliser ?

ou le forker….
http://linux.slashdot.org/story/14/09/21/1427240/fork-of-systemd-leads-to-lightweight-uselessd

J'aime beaucoup!

Bon il faut savoir que ça ne marche pas (bien) avec une version de git inférieure à 1.8.4

Ce que je trouve qui serais bien:
- pouvoir replier la liste des "tags" (car elle peut être longue et on ne la manipule pas tous les jours)
- pouvoir stager plusieurs lignes d'un hunk (pas, soit tout, soit ligne par ligne)
- pouvoir faire un reset ('cancel' dans git-webui, aussi souple que le staging, par ligne ou hunk)
- et le bonheur absolu, avoir une vue du dag…

Voilà pour les premiers retours.