D'un autre cote, t'es pas flic, t'as aucune experience des enlevements d'enfants donc ton avis, il vaut ce qu'il vaut, c'est a dire pas grand chose...
Comme j'ai coutume de dire : les avis, c'est comme les trous du cul, tout le monde en a un...
- Tu n'as pour information que ce que la police/gendarmerie a bien voulu donner
- Cerise sur le gateau, tu dis toi meme n'avoir pas suivi toute l'affaire et donc n'avoir qu'un sous ensemble, surement deforme qui plus est, de ces infos...
- Tu ne connais ni de pres ni de loin les personnes impliquees dans l'affaire
- Tu n'as pas la moindre idee de ce que peuvent couter les mesures que tu preconises, leur efficacite, leur facilite de mise en oeuvre etc.
Bref, comme dirais nous amis d'outre manche/atlantique : you don't know jack.
Et tu viens l'ouvrir et expliquer comment ils auraient du faire...
zavez jamais pense a utiliser un vrai ide, du genre qui vous permet de faire une recherche dans tous les fichiers du projet, plutot que de jongler avec 4 applis en permanence?
Sinon, pour la gestion des rep, il suffit aussi de se def une variable correspondant à ton projet :-)
pffouuu..
ca fait chier. mon boulot c'est pas de me compliquer la vie alors que c'est le boulot d'une machine de gerer la presentation des infos.
D'autre part, je crois qu'on s'est mal compris, je parlais de naviguer dans une arborescence en ligne de commande : c'est pas pratique de naviguer dans un arbre avec une ligne de commande. Parce que tu n'as pas de vision globale.
je sais pas vous, mais sur un projet "classique" je touche pas les branches toutes les 5 min et il "suffit" de tagger car ça ça se fait très rapidement, y compris le swap sur la tête
ben chais pas, a chaque commit j'impacte bien 5 a 10 fichiers.
Et commiter sans verifier le diff pour chaque fichier, tres peu pour moi.
Bref le probleme vient plus d'une mauvaise presentation des infos du CVS (impossible de faire un diff lisible etc.) que du concept ligne de commande.
tout a fait d'accord avec toi par contre concernant l'integration a l'ide.
Premier point, lié a la ligne de commande : c'est conceptuellement particulierement inadapte pour gerer des fichiers (hors cas tres simples, avec une dizaines de fichiers dans un seul repertoire par ex). Les fichiers sont en effet dans un arbre et on fait bien mieux que de l'ascii art pour representer un arbre, tout de meme ;-)
Bon apres, j'suis dev java, un repertoire par package, t'imagines vite le bordel a se fader des cd com/maboite/monprojet/package/souspackage, cd ../../../../../ etc.
M'enfin, l'idee est la quoi.
Sinon, syntaxe aride, commandes cryptiques, enchainement particulierement relou de commandes (pour supprimer un repertoire et son contenu, par ex), page man longue comme ma teub (i.e. : gros, tres gros ^_^) etc.
Lever un conflit de commit en ligne de commande, ben voila quoi.
Rien que pour supprimer un fichier : rm fichier cvs delete fichier, cvs commit, ca fait une operation de trop ('fin a mon gout, hein).
Un client CVS graphique decent t'affichera directement un diff graphique avec toute les facilites pour naviguer (perso, j'utilise enormement la perspective CVS/Team synchronise d'eclipse, ben quand meme ca simplifie la vie)
En tout cas dans une utilisation pro, CVS en ligne de commande me parait totalement inutilisable.
Techniquement, je l'ai fait, sur un petit projet ou j'avais une partie du boulot a faire en ssh sur une machine distante, avec 4-5 fichiers max a manipuler, c'etait deja penible, j'ose pas imaginer quand je commit mes 15 classes (en fait, dans ce cas la, j'aurais rappatrié les sources sur mon poste local et j'aurais commite dans mon eclipse).
Tres recemment, j'ai du me fader l'historique de mes commits pour retrouver un jar bien particulier : selection de la vue "historique", dnd du fichier dans la vue, ya plus qu'a click droit sur chaque revision, get Contents, double click et paf, j'ai ce qu'il me faut sous la main, le tout avec la date du commit, le ocmmentaire, le numero de verison etc sous les yeux et bien organise.
Va naviguer parmi les tags/branches etc dans un client ligne de commande.
Va checkouter une version anterieure a une certaine date en ligne de commande, entre un calendrier graphique et la saisie de la date manuellement ya pas photo, mon choix est vite fait.
Apres, si c'est juste pour faire un checkout d'un projet sur 'ternet, ./configure && make, c'est sur que c'est plus rapide que de sortir un gros client graphique.
Je connais pas du tout SVN, mais il m'a l'air tout a fait calqué sur CVS niveau utilisation.
Ce site web, c'est un délire, je ne vois pas comment un individu normalement constitué peut prendre ce site au sérieux rien qu'en en voyant les images.
ben visiblement, on est quelques uns normalement constitue dans ces colonnes a l'avoir prit plus ou moins au serieux. Recherche dunc bank dans la pitite boite en haut a droite, tu verras bien.
Disons qu'abstraction faite du ton et des images, on se doute qu'il ya qqchose de serieux deriere.
Ce qui a l'air d'etre le cas, vu comment tu prends le sujet a coeur.
Et excuse-moi, mais qui crois-tu convaincre en disant qu' « au final c'est pas si évident que ça » ?
j'ai l'impression qu'on s'est mal compris.
Par "pas si evident que ca", j'entendais qu'a la lumiere de ton commentaire, c'etait pas evident que l'initiative soit simplement un conflit de personnes.
En revanche, ta page dunc bank donne simplement l'impression de vouloir casser du dunk tank.
C'est tout.
Apres ya ptetre eu mauvaise comprehension, mais faut etre 2 pour ca...
ben on retombe dans ce que je disais plus bas : communiquez un peu mieux que ca, bordel...
Si le management est incompetent (en vrai j'en sais rien, j'ai pas de quoi juger), soit.
Maintenant, expliquer le probleme un peu mieux ne ferait pas de mal, parce que la tu vois, t'es passe tout seul pour un agite du bocal en faisant des privates jokes de geek initie alors qu'au final c'est pas si evident que ca (pas si evident car je n'ai pas les moyen de verifier, encore une fois).
Bref, c'est pas le tout d'etre de bonne foi et de penser avoir raison, faut encore etre capable de le faire comprendre aux autres (et le pire c'est que t'en es visiblement capabel, vu la reponse que tu viens de faire).
Bref entre "bouh, dunk tank c'est nul, ils payent des dev et pas d'autres, on va tout faire pour faire capoter le truc" et la reponse que tu viens de me donner, ya un monde...
Derniere chose, j'ai pas dit que l'estimation faite par le management debian etait correcte, juste que c'etait pas "broken by design" de faire une estimation correcte, nuance.
À la fois en améliorant la qualité de la distribution par d'autres moyens, et en nuisant directement à dunc-tank.
J'ai du mal a saisir comment tirer publiquement dans les pattes de ses collegues va ameliorer la qualite.
et parce que l'image de dunc-tank s'est cassée la gueule quand il est devenu évident que le retard serait supérieur à un mois.
mouais, enfin la grande question est : est ce que le retard aurait ete inferieur a un mois si certains n'avaient pas volontairement freine des 2 pieds pour porter ce delai a plus d'un mois?
Ben ecoutes, c'est ton site, c'est ptetre meme toi qui l'a redige (en tout cas t'en es assez proche, vu ton lien page perso).
Je lit ca dessus :
We hope that by finding more and more RC bugs in Debian we can delay Etch.
Le sens de cette phrase est en substance : nous esperons qu'en trouvant plein de bugs RC, on peut retarder Etch.
Ceci est renforce par le ton de la page et par le nom meme du projet, qui est une reference directe a dunk tank.
Sens qui en decoule : la recherche de bug n'est qu'un moyen pour atteindre le but "retarder Etch".
Retarder Etch est une fin en soi, c'est ce que j'appelle contre productif.
Apres si c'est pas le cas, je m'en excuse platement, mais va falloir prendre des cours de communication...
Cela dit, j'ai comme un gros doute, tu vois.
Deuxieme chose, je ne donne pas de lecons.
Je me permet juste de reagir sur le fait que tu presentes dunc bank comme une procedure QA pour debian alors que ca n'est visiblement qu'une querelle interne a debian.
Apres ce que tu fais chez debian je m'en tamponne le coquillard d'une force, mais alors d'une force...
Ne pas prétendre dès le début qu'on sait exactement à quoi ressemblera le produit fini
C'est sur que quand on sait pas ou on va, c'est pas possible de mettre une deadline...
M'enfin c'est gonfle de venir donner des lecons de QA et de gestion de projet quand a l'etape du freeze, on ne sait toujours pas ce qu'on est cense produire, tu m'excuseras...
La totalité des SSII fonctionnent comme ça. La quasi totalité des projets dépasse les deadlines.
2 choses :
1) les deadlines sont depasses car le client tire le prix vers le bas au max. Pas l'impression qu'il y ait grand monde qui tire quoi que ce soit vers le bas dans le cas de debian
2) entre deriver de pourcents et atomiser la date prevue en doublant le temps de dev initialement prevu, ya une certaine difference...
Bref, mauvaise foi, mauvaise foi, quand tu tiens...
Pourquoi vous ne l'admettez pas clairement?
Le but de ce projet est d'emmerder le plus possible dunk tank. Au moins on sait sur quelles bases on part et puis voila...
quand je lit ca : We hope that by finding more and more RC bugs in Debian we can delay Etch.
je me dit que l'essence meme de dunc bank est d'etre anti productif au possible...
le but du jeu n'est pas d'ameliorer etch, mais juste de la retarder pour n'importe quel motif.
Le but ultime est visiblement de juste faire echouer dunk tank, pour pouvoir leur dire "ah ben vous voyez, ca marche pas, on vous l'avez dit, Ha-Ha!!".
'fin bref, arreter de prendre les gens pour des jambons, et eviter de faire passer une querelle interne pour une procedure de QA.
Ben justement l'ipod c'est typiquement le genre de produit qui peut evoluer en pda ;-)
Il permet deja de stocker en lecture seule ses contacts et calendrier (en lecture seule, ca limite grandement l'interet, il est vrai).
Ajoute a ca les jeux et la fonction de recherche sur la derniere generation, on se rapproche plus d'un genre hybride de pda que d'un simple decodeur mp3.
Cela dit, vu la cible d'apple et sa resolution de simplicite, je doute que ca aille vraiment dans la direction d'une machine a tout faire.
[^] # Re: Bientôt sur vos écrans
Posté par ola . En réponse au journal Adresse à coucher dehors. Évalué à 3.
D'un autre cote, t'es pas flic, t'as aucune experience des enlevements d'enfants donc ton avis, il vaut ce qu'il vaut, c'est a dire pas grand chose...
Comme j'ai coutume de dire : les avis, c'est comme les trous du cul, tout le monde en a un...
- Tu n'as pour information que ce que la police/gendarmerie a bien voulu donner
- Cerise sur le gateau, tu dis toi meme n'avoir pas suivi toute l'affaire et donc n'avoir qu'un sous ensemble, surement deforme qui plus est, de ces infos...
- Tu ne connais ni de pres ni de loin les personnes impliquees dans l'affaire
- Tu n'as pas la moindre idee de ce que peuvent couter les mesures que tu preconises, leur efficacite, leur facilite de mise en oeuvre etc.
Bref, comme dirais nous amis d'outre manche/atlantique : you don't know jack.
Et tu viens l'ouvrir et expliquer comment ils auraient du faire...
[^] # Re: Mon expérience actuelle
Posté par ola . En réponse au journal Bonnes pratique pour le développement. Évalué à -1.
zavez jamais pense a utiliser un vrai ide, du genre qui vous permet de faire une recherche dans tous les fichiers du projet, plutot que de jongler avec 4 applis en permanence?
[^] # Re: Vocabulaire
Posté par ola . En réponse au journal Bonnes pratique pour le développement. Évalué à 1.
pffouuu..
ca fait chier. mon boulot c'est pas de me compliquer la vie alors que c'est le boulot d'une machine de gerer la presentation des infos.
D'autre part, je crois qu'on s'est mal compris, je parlais de naviguer dans une arborescence en ligne de commande : c'est pas pratique de naviguer dans un arbre avec une ligne de commande. Parce que tu n'as pas de vision globale.
je sais pas vous, mais sur un projet "classique" je touche pas les branches toutes les 5 min et il "suffit" de tagger car ça ça se fait très rapidement, y compris le swap sur la tête
ben chais pas, a chaque commit j'impacte bien 5 a 10 fichiers.
Et commiter sans verifier le diff pour chaque fichier, tres peu pour moi.
Bref le probleme vient plus d'une mauvaise presentation des infos du CVS (impossible de faire un diff lisible etc.) que du concept ligne de commande.
tout a fait d'accord avec toi par contre concernant l'integration a l'ide.
[^] # Re: Vocabulaire
Posté par ola . En réponse au journal Bonnes pratique pour le développement. Évalué à 2.
Bon apres, j'suis dev java, un repertoire par package, t'imagines vite le bordel a se fader des cd com/maboite/monprojet/package/souspackage, cd ../../../../../ etc.
M'enfin, l'idee est la quoi.
Sinon, syntaxe aride, commandes cryptiques, enchainement particulierement relou de commandes (pour supprimer un repertoire et son contenu, par ex), page man longue comme ma teub (i.e. : gros, tres gros ^_^) etc.
Lever un conflit de commit en ligne de commande, ben voila quoi.
Rien que pour supprimer un fichier : rm fichier cvs delete fichier, cvs commit, ca fait une operation de trop ('fin a mon gout, hein).
Un client CVS graphique decent t'affichera directement un diff graphique avec toute les facilites pour naviguer (perso, j'utilise enormement la perspective CVS/Team synchronise d'eclipse, ben quand meme ca simplifie la vie)
En tout cas dans une utilisation pro, CVS en ligne de commande me parait totalement inutilisable.
Techniquement, je l'ai fait, sur un petit projet ou j'avais une partie du boulot a faire en ssh sur une machine distante, avec 4-5 fichiers max a manipuler, c'etait deja penible, j'ose pas imaginer quand je commit mes 15 classes (en fait, dans ce cas la, j'aurais rappatrié les sources sur mon poste local et j'aurais commite dans mon eclipse).
Tres recemment, j'ai du me fader l'historique de mes commits pour retrouver un jar bien particulier : selection de la vue "historique", dnd du fichier dans la vue, ya plus qu'a click droit sur chaque revision, get Contents, double click et paf, j'ai ce qu'il me faut sous la main, le tout avec la date du commit, le ocmmentaire, le numero de verison etc sous les yeux et bien organise.
Va naviguer parmi les tags/branches etc dans un client ligne de commande.
Va checkouter une version anterieure a une certaine date en ligne de commande, entre un calendrier graphique et la saisie de la date manuellement ya pas photo, mon choix est vite fait.
Apres, si c'est juste pour faire un checkout d'un projet sur 'ternet, ./configure && make, c'est sur que c'est plus rapide que de sortir un gros client graphique.
Je connais pas du tout SVN, mais il m'a l'air tout a fait calqué sur CVS niveau utilisation.
[^] # Re: Vocabulaire
Posté par ola . En réponse au journal Bonnes pratique pour le développement. Évalué à -5.
[^] # Re: ceci explique cela
Posté par ola . En réponse au journal Décideurs pressé et Vista. Évalué à 3.
[^] # Re: C'est qui Etch
Posté par ola . En réponse au journal Etch sous la barre des 100. Évalué à 0.
ben visiblement, on est quelques uns normalement constitue dans ces colonnes a l'avoir prit plus ou moins au serieux. Recherche dunc bank dans la pitite boite en haut a droite, tu verras bien.
Disons qu'abstraction faite du ton et des images, on se doute qu'il ya qqchose de serieux deriere.
Ce qui a l'air d'etre le cas, vu comment tu prends le sujet a coeur.
Et excuse-moi, mais qui crois-tu convaincre en disant qu' « au final c'est pas si évident que ça » ?
j'ai l'impression qu'on s'est mal compris.
Par "pas si evident que ca", j'entendais qu'a la lumiere de ton commentaire, c'etait pas evident que l'initiative soit simplement un conflit de personnes.
En revanche, ta page dunc bank donne simplement l'impression de vouloir casser du dunk tank.
C'est tout.
Apres ya ptetre eu mauvaise comprehension, mais faut etre 2 pour ca...
[^] # Re: C'est qui Etch
Posté par ola . En réponse au journal Etch sous la barre des 100. Évalué à 1.
Si le management est incompetent (en vrai j'en sais rien, j'ai pas de quoi juger), soit.
Maintenant, expliquer le probleme un peu mieux ne ferait pas de mal, parce que la tu vois, t'es passe tout seul pour un agite du bocal en faisant des privates jokes de geek initie alors qu'au final c'est pas si evident que ca (pas si evident car je n'ai pas les moyen de verifier, encore une fois).
Bref, c'est pas le tout d'etre de bonne foi et de penser avoir raison, faut encore etre capable de le faire comprendre aux autres (et le pire c'est que t'en es visiblement capabel, vu la reponse que tu viens de faire).
Bref entre "bouh, dunk tank c'est nul, ils payent des dev et pas d'autres, on va tout faire pour faire capoter le truc" et la reponse que tu viens de me donner, ya un monde...
Derniere chose, j'ai pas dit que l'estimation faite par le management debian etait correcte, juste que c'etait pas "broken by design" de faire une estimation correcte, nuance.
[^] # Re: C'est qui Etch
Posté par ola . En réponse au journal Etch sous la barre des 100. Évalué à 0.
J'ai du mal a saisir comment tirer publiquement dans les pattes de ses collegues va ameliorer la qualite.
et parce que l'image de dunc-tank s'est cassée la gueule quand il est devenu évident que le retard serait supérieur à un mois.
mouais, enfin la grande question est : est ce que le retard aurait ete inferieur a un mois si certains n'avaient pas volontairement freine des 2 pieds pour porter ce delai a plus d'un mois?
[^] # Re: C'est qui Etch
Posté par ola . En réponse au journal Etch sous la barre des 100. Évalué à -1.
Je lit ca dessus :
We hope that by finding more and more RC bugs in Debian we can delay Etch.
Le sens de cette phrase est en substance : nous esperons qu'en trouvant plein de bugs RC, on peut retarder Etch.
Ceci est renforce par le ton de la page et par le nom meme du projet, qui est une reference directe a dunk tank.
Sens qui en decoule : la recherche de bug n'est qu'un moyen pour atteindre le but "retarder Etch".
Retarder Etch est une fin en soi, c'est ce que j'appelle contre productif.
Apres si c'est pas le cas, je m'en excuse platement, mais va falloir prendre des cours de communication...
Cela dit, j'ai comme un gros doute, tu vois.
Deuxieme chose, je ne donne pas de lecons.
Je me permet juste de reagir sur le fait que tu presentes dunc bank comme une procedure QA pour debian alors que ca n'est visiblement qu'une querelle interne a debian.
Apres ce que tu fais chez debian je m'en tamponne le coquillard d'une force, mais alors d'une force...
[^] # Re: C'est qui Etch
Posté par ola . En réponse au journal Etch sous la barre des 100. Évalué à 0.
C'est sur que quand on sait pas ou on va, c'est pas possible de mettre une deadline...
M'enfin c'est gonfle de venir donner des lecons de QA et de gestion de projet quand a l'etape du freeze, on ne sait toujours pas ce qu'on est cense produire, tu m'excuseras...
La totalité des SSII fonctionnent comme ça. La quasi totalité des projets dépasse les deadlines.
2 choses :
1) les deadlines sont depasses car le client tire le prix vers le bas au max. Pas l'impression qu'il y ait grand monde qui tire quoi que ce soit vers le bas dans le cas de debian
2) entre deriver de pourcents et atomiser la date prevue en doublant le temps de dev initialement prevu, ya une certaine difference...
Bref, mauvaise foi, mauvaise foi, quand tu tiens...
Pourquoi vous ne l'admettez pas clairement?
Le but de ce projet est d'emmerder le plus possible dunk tank. Au moins on sait sur quelles bases on part et puis voila...
[^] # Re: C'est qui Etch
Posté par ola . En réponse au journal Etch sous la barre des 100. Évalué à -1.
En quoi faire des estimations correctes du boulot restant a faire est broken by design?
La totalite de l'industrie moderne fonctionne comme ca, et pourtant ca a l'air de tres bien marcher...
Ensuite la seule chose qui va etre montree par l'experience c'est que les mecs de dunc bank sont des irresponsables, caracteriels et jaloux...
[^] # Re: C'est qui Etch
Posté par ola . En réponse au journal Etch sous la barre des 100. Évalué à 1.
Elle a bon dos la discussion saine.
quand je lit ca :
We hope that by finding more and more RC bugs in Debian we can delay Etch.
je me dit que l'essence meme de dunc bank est d'etre anti productif au possible...
le but du jeu n'est pas d'ameliorer etch, mais juste de la retarder pour n'importe quel motif.
Le but ultime est visiblement de juste faire echouer dunk tank, pour pouvoir leur dire "ah ben vous voyez, ca marche pas, on vous l'avez dit, Ha-Ha!!".
'fin bref, arreter de prendre les gens pour des jambons, et eviter de faire passer une querelle interne pour une procedure de QA.
[^] # Re: ...
Posté par ola . En réponse au journal Le Nokia N800 est sorti!. Évalué à 0.
ca a l'air allechant ce machin la...
manque encore un peu de disque dur pour venir titiller l'ipod video, mais ca ne saurait tarder a evoluer :p
[^] # Re: ...
Posté par ola . En réponse au journal Le Nokia N800 est sorti!. Évalué à -1.
Il permet deja de stocker en lecture seule ses contacts et calendrier (en lecture seule, ca limite grandement l'interet, il est vrai).
Ajoute a ca les jeux et la fonction de recherche sur la derniere generation, on se rapproche plus d'un genre hybride de pda que d'un simple decodeur mp3.
Cela dit, vu la cible d'apple et sa resolution de simplicite, je doute que ca aille vraiment dans la direction d'une machine a tout faire.
[^] # Re: Le prends pas mal mais...
Posté par ola . En réponse au journal Une histoire vrai.... Évalué à 2.
beeeeen...
techniquement, si. :-P
http://en.wikipedia.org/wiki/Alan_Turing#Prosecution_for_hom(...)