Non, mais tu as le coté vitrine de la chose. Tu montres qui tu suis (ce qui est franchement un peu naze), les projets mettent en avant le nombre de contributeurs et d'étoiles, et tu as une liste de ce que tel personne a fait.
Ceci dit, github a changé son slogan maintenant "where software is built".
D'abord, je ne pense pas qu'on puisse dire "c'est verrouillé" ou "c'est pas verrouillé" vis à vis d'une migration.
C'est plus un spectre de possibilité, allant de "c'est facile de bouger" à "c'est très couteux". L'API aide, mais si tu as rien pour recevoir les données, tu va pas loin. Et l'API, c'est juste un truc sympa pour t'éviter de faire du scrapping, qui est pas non plus du domaine de l'impossible.
Ensuite, même avec l'API, tu restes coincé sur les comptes, et malgré le fait que des choses existes (openid, saml, persona), on s'apercoit qu'au final, les entreprises préferent mettre des moyens pour que tu restes chez elles (et donc parfois avoir tes infos) que de pousser vers la décentralisation. Donc tu as une forte adhérence à ce niveau.
Et ton nouveau BT va devoir faire un mapping d'info que tu n'as peut être pas pas (email, mot de passe).
Enfin, je pense que la partie verouillage, c'est pas sur le fait de rester sur la plateforme plus que le fait que la gestion des bugs de github est des plus primitives.
Par exemple, tu ne peux pas faire des bugs privés, ce qui est pas terrible pour les failles de sécurité, et du coup, tu te retrouves avec une procédure différente pour ce genre de bugs, et une procédure moins testé, qu'est ce qui peut arriver de mal…
Autre exemple, tu ne peux pas déléguer la classification des bugs sans donner de droits de commits, dans mon souvenir, ce qui est aussi contre productif.
Et je parle que des trucs de bases, je vais même pas chercher du coté automatisation, ou finalement, tu es obligé d'avoir un login/password pour un bot, ce qui l'expose à des risques non requis, et entraine des complications.
Donc oui, github va bien pour des petits projets du dimanche, mais dés que tu grandit, tu te retrouve avec des trucs qui coincent et ou tu peux pas faire grand chose.
(et bien sur, ça reste proprio et centralisé, ce qui visiblement emmerde pas grand monde au sein du libre, et je pourrais sans doute faire un livre entier sur le sujet…)
Alors les serveurs sont pas de Red hat (pas tous), mais de la fondation Gnome. Il y a plein de sponsors (dont Canonical par exemple), mais les serveurs sont un peu vieux, et l'équipe de sysadmin Gnome (à savoir 1 volontaire et 1 à mi temps) est en train de mettre à jour le hardware.
Pour la bande passante, je viens de regarder sur les graphs et j'ai pas l'impression que ça soit saturé à la sortie du DC (qui a 2 liens. Je pense que c'est plutôt coté serveur du coup, soit coté disque, soit c'est un vieux serveur qui est pas en giga ou pas sur un switch giga.
Pour compléter, l'activation par socket permet en effet l'activation automatique, mais pas uniquement, ça permet aussi de démarrer les choses plus ou moins dans le désordre sans avoir des races conditions compliqués à déboguer (cf http://0pointer.de/blog/projects/systemd.html).
Par exemple, Sauron a crée de l'emploi et à revitaliser le tissu socio économique du Mordor via sa politique de grands travaux, et j'ai entendu dire que c'était aussi un peintre amateur. Certes, il y a eu quelque incidents par ci par la qui ont émaillés son règne et sa politique expansionniste parait surannée maintenant, mais dans le contexte de l'époque, il a négocié la transition vers l'industrialisation.
En effet, en relisant, j'ai trouvé plus. Ensuite, sur les 8, j'en compte 3 dont la contribution est d'avoir été la femme/compagne/victime d'un des autres membres de la liste.
C'est marrant qu'on soit dans une communauté dont la base est la collaboration, mais que les gens préfèrent quand même mettre en avant l'individuel plutôt que le collectif.
(individu qui sont quand même tous dans le même moule quand on regarde ta sélection mais bon, on va pas parler de la diversité, on va se fâcher).
Parcequ'il n'y a aucune volonté que cela le soit ?
je connais plein de gens qui le voudrais, donc la volonté est la.
Il n'y a pas exclusion mutuelle entre ces affirmations (me semble t il)
Et pourtant si.
Si les décisions sont prises pour des raisons purement techniques, alors une raison non technique prouve que les décisions ne sont pas prises que sur la technique, et donc que les affirmations "on prends en compte que la technique" est visiblement fausse. De la à dire que ce patch est juste un exemple parmi tant d'autres, il y a un pas que je n'hésite pas à franchir.
C'est pas dur de trouver des gens qui vont dire que Brad Spengler a l'air d'avoir une certaine colère dans ses écrits et visiblement n'attire pas grand monde pour bosser avec lui ou faire des efforts.
Même si des gens dans la communauté du libre rationalise ce comportement comme une qualité (sans doute parce que ne pas pointer les soucis des gens permet de justifier notre propre comportement vis à vis des autres), ça reste dans son cas un comportement antisocial. Et sauf à me trouver assez de gens qui vont me dire clairement et sérieusement "moi, j'aimerais bosser avec lui", je pense qu'il y a personne (à tort ou à raison) voulant le faire.
Donc ouais, je persiste à dire que "meritocratie mes fesses".
Si la qualité technique n'est pas remise en cause, pourquoi c'est pas upstream ? ( sauf à dire que le kernel n'est pas une meritocracie comme on le dit si souvent, et qu'au final, l'humain joue )
La rumeur semble dire qu'ils n'ont pas tant de 0 days à eux que ça. De ce que j'ai vu/lu, il y a une faille dans flash qui a été trouvé, mais c'est tout.
Le souci est même pas au niveau de comprendre. Le souci est déja juste au niveau d'exprimer son avis. Une situation des plus complexe ne peut pas à mon sens être résumé à un choix binaire fait à un moment T.
Et donc dire que le peuple s'est exprimé en lui prêtant une expression mono syllabique face à une question est plutôt insultant pour lui. On a globalement 1 bit d'information après passage de la moulinette des votes.
C'est mieux que rien, mais se gargariser de ça comme étant l'expression du peuple, c'est salement réducteur.
En même temps, c'est les tarifs des formations, il faut payer la personne qui parle (qui doit avoir quand même une sacré expertise), faut payer les locaux, les machines (et surtout le fait que les machines doivent pas tomber en panne pendant l'usage).
y a la préparation du cours par le formateur avant et de la salle.
Je ne peux m’empêcher de remarquer que le site web en anglais ne fait pas très sérieux :
"Systematic Paris-Region Tarsus and announce the merger salons Solutions Linux / Open Source and Open World Forum "
je suis pas traducteur, mais je pense que "Systematic Paris-Region and Tarsus announce the merge of Solution Linux / Open Source and Open World Forum". Et c'est que la première page.
Cliquer sur un lien bascule à nouveau vers du français la plupart du temps, et je trouve les tournures de phrases assez curieuses (mais techniquement correct) comme "arisen from", "associative village".
J'aurais bien passer le CfP a mes collègues anglophones en dehors de france, mais comme la traduction en anglais est "in progress", j'ai pas envie de passer pour un rigolo. Mais comme le CfP est ouvert que pour 3 semaines, ça va faire short. Pour quelque chose d'envergure européen, ça le fait pas.
Alors je comprends les soucis d'avoir du travail, de tenir les délais, etc, etc. Mais ça ne réhausse pas hélas ma vision de ces 2 événements combinés.
Non, c'était pas un des buts de l'assoce, ni du projet. On s'est pas dit "tiens, on va faire une assoce pour que nos quelques potes fassent des thunes". Les gens de hupstream ont dit "on va monter une boite à coté parce qu'on a envie d'être à notre compte" mais c'etait pas "on va monter une boite pour faire du service".
Et de ce que je sais, Mageia est pas vraiment ce qui rapporte des affaires à Hupstream (à part via Mandriva, mais c’était pas vraiment un truc prévu). Ils font des formations, il y a eu des contrats de portages divers et variés, le fait de proposer Debian dans Azure, etc, etc.
je pense du bien de Debian en tant que communauté et que projet, tout comme beaucoup de projets. C'est pas parce que je trouve un truc stupide que ça discrédite tout le reste du travail accompli par des volontaires.
Ensuite, oui, je pense la même chose de "ça sortira quand ça sera prêt", avec le bemol que Debian en tant que communauté a réalisé que c'est un souci après la sortie de Sarge, et que les paquets avec des bugs RC non corrigés sont retiré de la distribution. Ou ils ont réalisés aussi que garder des vielles archis qui bloquent la release n'est pas forcement une chose à faire.
Ensuite, globalement, comme souvent dans le libre, la méthodologie de test est assez curieuse quand on regarde de manière plus distante. Globalement, on considère que si y a pas de bugs critiques ouverts, alors c'est bon. Alors qu'on devrait plutôt à priori dire qu'un paquet ne marche pas sauf si il a été explicitement testé, avec un jeu de test pour savoir à quoi s'attendre.
Mais ça, ça impliquerais d'avoir des gens volontaires pour le faire, et pour diverses raisons, c'est pas le cas. Des raisons aussi diverses que "on ne célèbre que les codeurs/packageurs la plupart du temps".
Typiquement, ça aboutit à des choses comme "seuls les packageurs ont le droit de vote" (comme c'était le cas chez Debian avant), les packageurs ont un alias mail et pas les gens de la QA (exemple, chez mageia au début, en partie parce que la QA n'avait pas de structure du point de vue du LDAP, et parce que le souci n’était pas aussi visible pour moi que maintenant). Je ne sais pas qui fait la QA de Gnome ou KDE par exemple.
Mon taf est d'être sysadmin, je bosse sur des projets libres à aider pour l'infra, et je peux même pas te citer 3 logiciels de gestion de tests QA libre, alors que j'arrive à trouver de tête 5 bugtrackers, 3 serveurs webs, et 5 outils de gestions de configuration. Et si on voit wikipedia, c'est pas glorieux (https://en.wikipedia.org/wiki/Test_management_tools). Le tableau n'est pas complet et j'en trouve d'autres (http://www.opensourcetestmanagement.com/), mais c'est le point. C'est que c'est tellement vu comme un marché de niche par les libristes que wikipedia a moins d'informations sur ça que sur la musique country de Nashville.
Alors, ça, c'est une vielle discussion. Le but de Mageia était aussi de pas jeter à la poubelle tout le travail fait par Mandriva et de mettre la communauté Mandriva aux commandes, et d'avoir son indépendance vis à vis des soucis commerciaux.
Donc rejoindre opensuse n'aurais aider sur aucun de ses 2 points (à commencer par le second).
Mais maintenant, peut être que tu penses que tout ce travail aurait du être balancé à la poubelle, et que finalement, dépendre d'une boite commercial n'était pas un objectif valable, ce qui serait ton droit, mais dans ce cas, faut le dire clairement.
Evidemment que le respect des délais est un objectif à tenter
de tenir. Tout est question de dosage entre le niveau de
qualité attendu et l'importance des délais.
Alors en fait, si tu dis aux gens "Est ce qu'il faut respecter les délais", la réponse va être "Oui, bien sur". Mais la ou ça coince, c'est quand on va dire comment ça arrive que les gens le font pas.
Tout le monde est d'accord sur le fait d'augmenter la qualité, mais quand augmenter la qualité implique de virer des paquets, ça rale chez Mageia. Tout le monde est d'accord pour augmenter la qualité, mais quand ça requiert de faire plus de tests et/ou réduire la voilure, c'est pareil chez Fedora, les gens grognent.
Donc dire "c'est important" et avoir l'aval des gens de la communauté n'a vraiment d'importance que si les gens ne comprennent pas l'impact, et je pense que dans le libre comme ailleurs, les gens ne cherchent pas à avoir "the big picture".
Tu peux bien critiquer les process, pointer les erreurs qui
ont été commises, mais quel est le but ? Personne n'a dit
qu'ils étaient parfaits :)
Le but n'est pas de critiquer le processus ou les personnes, sinon, j'aurais donné des noms, pour commencer, si le but était de faire porter le chapeau à quelqu'un.
Le but est de montrer que l'état d'esprit "on sort quand c'est prêt" a des ramifications profondes.
Je n'ai pas dit ça, les délais c'est important, la qualité
aussi.
Mais les gens implicitement semblent opposer la qualité et les délais, cf le message qui a commencé ce thread, cf toi même plus haut en parlant de dosage entre les 2, et cf la tonne d'exemple de debianneux qui ont le même avis.
C'est une fausse dichotomie et c'est ça le souci.
Tu peux aussi avoir la qualité et tenir des délais mais il faut réduire sur un autre axe, celui des nouveautés et de la charge de travail, et faire que la qualité soit une priorité plus grande que la nouveauté (dans l'esprit de la communauté). Sauf que l'axe en question est quasiment sacré partout, et personne ne semble le remettre en cause sauf dans de rares cas. Quand un truc change l'interface des utilisateurs, alors soudainement, des gens protestent mais c'est plus un rejet qu'une réflexion poussé sur la charge de travail (comme on peut le voir notamment avec le rejet de systemd).
Par exemple, chez Fedora, il a été dit "non" au passage à gcc 5.1 mais il est quand même passé. J'ai vu moins de 1% de paquets refusé lors du version freeze chez Mageia et la seul fois ou je me souviens d'un "non", c'est quand même passé.
Tout le monde va être d'accord sur "faut de la qualité", mais personne ne veut vraiment garder à l'idée que faire des paquets n'est qu'une sous partie du travail. Par exemple
Il y a un temps où tu aurais répondu, à qui ferait ce genre de
remarque : les contributions sont les bienvenues, ça ne sert à
rien de râler, il faut s'impliquer si on veut que ça bouge. Où
est passé ce misc là ?
J'ai jamais eu de dédoublement de personnalité au point de me répondre à moi même, donc même au temps ou j'aurais répondu, je ne me serait pas répondu à moi même. Et tenter de faire changer les choses, j'ai déjà donné, le misc dont tu parles à largement payé le prix.
Il y a plein de bon sens dans ton message, mais je ne saisis
pas l'intention première.
On est sur Linuxfr, l'intention première, c'est de discuter. Je ne vois autre chose dans le concept de commenter un commentaire d'une news. Si je voulais vraiment donner plus d'expositions à mes idées, je pourrais juste faire une conférence, ouvrir un blog et faire de la pub sur twitter etc. Si j'avais à coeur d'influencer le projet d'une manière direct, je connais encore le chemin vers la liste de discussion.
Le vrai point positif c'est qu'on ne sort pas à une date fixe
à tout prix même si ça n'est pas prêt du tout, qu'on est prêts
à repousser si c'est nécessaire, même si ce n'est pas un but
en soi et qu'on aime tenir les délais.
Le simple fait de se dire que "tenir les délais" soit juste un "nice to have" est déjà un souci.
Par exemple, ça a des implications assez embêtantes pour publier un magazine avec, ça pose souci pour organiser un événement à l'avance, etc. Je ne verrais pas l'ubuntu party avoir autant de monde si l'équipe d'orga n'avait pas la certitude de la date de sortie par exemple.
Et contrairement à ce qu'on peut croire, avoir des délais n'est pas incompatible avec le fait d'être volontaire. Par exemple, l'organisation d'un événement (ou d'un mariage), le fait de publier un magazine (Linux mag spécial Perl/python/bsd/etc) sont autant d'exemple de choses ou une organisation de volontaire a marché, parce que le but est claire à atteindre et parce qu'on se dit pas "c'est ok d'être en retard".
Mageia 4 a été sorti à temps, c'est bien la preuve que ç'est faisable.
Mais le fait de se dire "ça arrive, on y peut rien" est sans doute une des raisons qui fait que je ne vois pas avoir de discussions ou d'annonce d'un postmortem pour voir ce qui a causé des soucis, et comment éviter ça pour le futur.
Parce que tout le monde a internalisé que c'est une bonne chose.
Pourtant, il suffit de lire le blog pour voir qu'il y a sans doute des choses à proposer et à discuter.
Et au vue des commits qui ont suivi, le paquet n'était clairement pas prêt.
Donc pourquoi avoir choisi de pousser rpm au lieu de faire d'abord une recompilation à part, puis de pousser une fois qu'on voit que ça ne casse pas tout ?
Pourquoi rpm 4.12 n'est pas passé comme une feature de mageia vu son potentiel à tout foutre en l'air, vu que le processus est modélisé sur la base de celui de Fedora. (et rpm 4.12 est passé comme feature chez Fedora par exemple)
Ce processus implique notamment de détailler quoi faire si ça va pas si c'est pas prêt à temps et comment revenir en arrière sans filer un truc pas prêt.
Mais la partie "on a un plan de secours pour s'assurer que les délais sont tenus", c'est visiblement totalement secondaire. Le template des features parle de conteingency, mais en regardant sur https://wiki.mageia.org/en/Category:ProposedFeatureMageia5
J'ai trouvé 5 features avec un plan de secours.
Sur un total de 21, c'est quand même assez peu. Et encore, aucune n'a de critère d'activation du plan de secours et je parle même pas du planning, qui est visiblement un peu pris à la légère.
Donc oui, la communauté se dit que c'est pas important de tenir les délais et que personne fait rien pour permettre de les tenir.
Un autre example, les mises à jours avec urpmi vont toujours de l'avant donc du coup, une fois qu'un truc est poussé, c'est dur de revenir en arrière dans Cauldron. Il faut mettre un tag epoch, et c'est "moche", et parfois pose des emmerdes.
Mais il est possible de faire des downgrades avec rpm (yum le fait depuis des années). Donc il suffirait juste de dire à urpmi que si le paquet est plus récent sur les dépots, on mets à jour, et si il est plus vieux, on rétrograde pour Cauldron. Et une fois en freeze, on reviens au mode normal avec mise à jour uniquement, mais plus grand contrôle de ce qui rentre.
Oui ou peut être un sérieux de ne pas vouloir sortir une
version buggué simplement pour faire plaisir…
Si un composant est trop problématique pour être corrigé à temps, il "suffit" de revenir en arrière avant la sortie.
Et ne pas tenir les délais a des conséquences sur le moral des gens, sur la capacité à planifier la sortie et divers autres choses. C'est pas juste "faire plaisir".
Et puis si pressé, je le dis la mais je l'ai dis souvent, on
peut faire en sorte que ça aille plus vite, suffit de participer…
En fait non, participer ne suffit pas, et je suis bien placé pour le savoir. Ça ne suffit pas parce que le souci est structurel et tu peux pas le corriger tout seul à contre courant. Ce qu'il faut changer, c'est pas le nombre de personnes, c'est les mentalités. La majorité des packageurs ont un conditionnement pavlovien sur la mise à jour des paquets (et l'ajout de nouveaux paquets) et une obsession de la nouveauté. Et ça a des impacts énormes sur l'équilibre des équipes les unes par rapport aux autres, sur la maintenance long terme et d'autres trucs.
n'a pas de delais de sortie, ça sort que quand c'est prêt, ça
vous rappel quelque chose?
ouais, plusieurs projets en retard chez divers clients par le passé, ou plusieurs émissions sur la gabégie des fonds publiques.
Je ne comprends que la communauté du libre se gargarise de pas savoir tenir les délais et d'être incapable d'en donner. Et l'excuse "on peut pas prévoir le travail requis" est pas moins valable pour le libre et les bénévoles que pour une boite. Dans une boite, tu peux avoir des gens qui partent, qui tombent malade et des soucis en tout genre.
C'est une chose d'avoir du retard, c'est une autre d'estimer que c'est un gage de qualité quand ça cache plus un manque de moyen.
[^] # Re: Verrouillage?
Posté par Misc (site web personnel) . En réponse au journal CPython abandonne Mercurial et passe à Git et Github. Évalué à 3.
Non, mais tu as le coté vitrine de la chose. Tu montres qui tu suis (ce qui est franchement un peu naze), les projets mettent en avant le nombre de contributeurs et d'étoiles, et tu as une liste de ce que tel personne a fait.
Ceci dit, github a changé son slogan maintenant "where software is built".
[^] # Re: Verrouillage?
Posté par Misc (site web personnel) . En réponse au journal CPython abandonne Mercurial et passe à Git et Github. Évalué à 10.
D'abord, je ne pense pas qu'on puisse dire "c'est verrouillé" ou "c'est pas verrouillé" vis à vis d'une migration.
C'est plus un spectre de possibilité, allant de "c'est facile de bouger" à "c'est très couteux". L'API aide, mais si tu as rien pour recevoir les données, tu va pas loin. Et l'API, c'est juste un truc sympa pour t'éviter de faire du scrapping, qui est pas non plus du domaine de l'impossible.
Ensuite, même avec l'API, tu restes coincé sur les comptes, et malgré le fait que des choses existes (openid, saml, persona), on s'apercoit qu'au final, les entreprises préferent mettre des moyens pour que tu restes chez elles (et donc parfois avoir tes infos) que de pousser vers la décentralisation. Donc tu as une forte adhérence à ce niveau.
Et ton nouveau BT va devoir faire un mapping d'info que tu n'as peut être pas pas (email, mot de passe).
Enfin, je pense que la partie verouillage, c'est pas sur le fait de rester sur la plateforme plus que le fait que la gestion des bugs de github est des plus primitives.
Par exemple, tu ne peux pas faire des bugs privés, ce qui est pas terrible pour les failles de sécurité, et du coup, tu te retrouves avec une procédure différente pour ce genre de bugs, et une procédure moins testé, qu'est ce qui peut arriver de mal…
Autre exemple, tu ne peux pas déléguer la classification des bugs sans donner de droits de commits, dans mon souvenir, ce qui est aussi contre productif.
Et je parle que des trucs de bases, je vais même pas chercher du coté automatisation, ou finalement, tu es obligé d'avoir un login/password pour un bot, ce qui l'expose à des risques non requis, et entraine des complications.
Donc oui, github va bien pour des petits projets du dimanche, mais dés que tu grandit, tu te retrouve avec des trucs qui coincent et ou tu peux pas faire grand chose.
(et bien sur, ça reste proprio et centralisé, ce qui visiblement emmerde pas grand monde au sein du libre, et je pourrais sans doute faire un livre entier sur le sujet…)
[^] # Re: Réaction à chaud
Posté par Misc (site web personnel) . En réponse à la dépêche GIMP a 20 ans !. Évalué à 6.
Alors les serveurs sont pas de Red hat (pas tous), mais de la fondation Gnome. Il y a plein de sponsors (dont Canonical par exemple), mais les serveurs sont un peu vieux, et l'équipe de sysadmin Gnome (à savoir 1 volontaire et 1 à mi temps) est en train de mettre à jour le hardware.
Pour la bande passante, je viens de regarder sur les graphs et j'ai pas l'impression que ça soit saturé à la sortie du DC (qui a 2 liens. Je pense que c'est plutôt coté serveur du coup, soit coté disque, soit c'est un vieux serveur qui est pas en giga ou pas sur un switch giga.
[^] # Re: présent à Paris
Posté par Misc (site web personnel) . En réponse à la dépêche Le Paris Open Source Summit arrive et LinuxFr.org sera là ! #OSSParis15. Évalué à 2.
ceci dit, le CIO summit aujourd'hui a été annulé.
[^] # Re: Fonctionnalité du patch
Posté par Misc (site web personnel) . En réponse au journal Busybox retire le support de systemd ?. Évalué à 5.
Oui, c'est ça.
Pour compléter, l'activation par socket permet en effet l'activation automatique, mais pas uniquement, ça permet aussi de démarrer les choses plus ou moins dans le désordre sans avoir des races conditions compliqués à déboguer (cf http://0pointer.de/blog/projects/systemd.html).
[^] # Re: une liste
Posté par Misc (site web personnel) . En réponse au journal Hommage aux Hackers moins-connus. Évalué à 5.
Question de point de vue.
Par exemple, Sauron a crée de l'emploi et à revitaliser le tissu socio économique du Mordor via sa politique de grands travaux, et j'ai entendu dire que c'était aussi un peintre amateur. Certes, il y a eu quelque incidents par ci par la qui ont émaillés son règne et sa politique expansionniste parait surannée maintenant, mais dans le contexte de l'époque, il a négocié la transition vers l'industrialisation.
[^] # Re: une liste
Posté par Misc (site web personnel) . En réponse au journal Hommage aux Hackers moins-connus. Évalué à 2.
En effet, en relisant, j'ai trouvé plus. Ensuite, sur les 8, j'en compte 3 dont la contribution est d'avoir été la femme/compagne/victime d'un des autres membres de la liste.
[^] # Re: une liste
Posté par Misc (site web personnel) . En réponse au journal Hommage aux Hackers moins-connus. Évalué à 5.
Amusant de voir qu'il y a bien plus de personnages imaginaires que de femmes dans ta liste (5), c'est assez troublant quand on y réfléchit.
# Quid du concept de travail d’équipe ?
Posté par Misc (site web personnel) . En réponse au journal Hommage aux Hackers moins-connus. Évalué à 8.
C'est marrant qu'on soit dans une communauté dont la base est la collaboration, mais que les gens préfèrent quand même mettre en avant l'individuel plutôt que le collectif.
(individu qui sont quand même tous dans le même moule quand on regarde ta sélection mais bon, on va pas parler de la diversité, on va se fâcher).
[^] # Re: Ça craint...
Posté par Misc (site web personnel) . En réponse au journal C'est officiel, la semaine 43 du calendrier n'existe plus et a été remplacée par la semaine 53.. Évalué à 7.
Alors, c'est visiblement lié à des conditions particulières sur le passage à l'heure d'été, dans des timezones spécifiques :
https://bugzilla.gnome.org/show_bug.cgi?id=736722
[^] # Re: Un prétexte uniquement ?
Posté par Misc (site web personnel) . En réponse au journal Grsecurity : le patch stable réservé aux sponsors. Évalué à 2.
Donc est ce qu'on peut dire qu'un patch difficile à relire est un patch de qualité correct ?
Si on le refuse pour ça, la réponse est "non".
[^] # Re: Un prétexte uniquement ?
Posté par Misc (site web personnel) . En réponse au journal Grsecurity : le patch stable réservé aux sponsors. Évalué à 4.
je connais plein de gens qui le voudrais, donc la volonté est la.
Et pourtant si.
Si les décisions sont prises pour des raisons purement techniques, alors une raison non technique prouve que les décisions ne sont pas prises que sur la technique, et donc que les affirmations "on prends en compte que la technique" est visiblement fausse. De la à dire que ce patch est juste un exemple parmi tant d'autres, il y a un pas que je n'hésite pas à franchir.
C'est pas dur de trouver des gens qui vont dire que Brad Spengler a l'air d'avoir une certaine colère dans ses écrits et visiblement n'attire pas grand monde pour bosser avec lui ou faire des efforts.
Même si des gens dans la communauté du libre rationalise ce comportement comme une qualité (sans doute parce que ne pas pointer les soucis des gens permet de justifier notre propre comportement vis à vis des autres), ça reste dans son cas un comportement antisocial. Et sauf à me trouver assez de gens qui vont me dire clairement et sérieusement "moi, j'aimerais bosser avec lui", je pense qu'il y a personne (à tort ou à raison) voulant le faire.
Donc ouais, je persiste à dire que "meritocratie mes fesses".
[^] # Re: Un prétexte uniquement ?
Posté par Misc (site web personnel) . En réponse au journal Grsecurity : le patch stable réservé aux sponsors. Évalué à 6.
Si la qualité technique n'est pas remise en cause, pourquoi c'est pas upstream ? ( sauf à dire que le kernel n'est pas une meritocracie comme on le dit si souvent, et qu'au final, l'humain joue )
[^] # Re: Occident ?
Posté par Misc (site web personnel) . En réponse au journal La trahison de qui ?. Évalué à 2.
On m'a toujours dit que l'orient, c'était à l'est.
C'est compliqué ces histoires de points cardinaux, c'est jamais pareil selon la ou on regarde.
[^] # Re: J'espere qu'on saura en profiter
Posté par Misc (site web personnel) . En réponse au journal hacked Team : qui vit par l’épée périra par l’épée. Évalué à 6.
La rumeur semble dire qu'ils n'ont pas tant de 0 days à eux que ça. De ce que j'ai vu/lu, il y a une faille dans flash qui a été trouvé, mais c'est tout.
[^] # Re: Pourquoi le non est-il la démocratie ?
Posté par Misc (site web personnel) . En réponse au journal Et ce soir, la démocratie l'emporte !. Évalué à 5.
Le souci est même pas au niveau de comprendre. Le souci est déja juste au niveau d'exprimer son avis. Une situation des plus complexe ne peut pas à mon sens être résumé à un choix binaire fait à un moment T.
Et donc dire que le peuple s'est exprimé en lui prêtant une expression mono syllabique face à une question est plutôt insultant pour lui. On a globalement 1 bit d'information après passage de la moulinette des votes.
C'est mieux que rien, mais se gargariser de ça comme étant l'expression du peuple, c'est salement réducteur.
[^] # Re: 3 jours à 2395€HT
Posté par Misc (site web personnel) . En réponse à la dépêche Alter Way, partenaire de Mirantis, propose les formations officielles OpenStack Bootcamp en français. Évalué à 4.
En même temps, c'est les tarifs des formations, il faut payer la personne qui parle (qui doit avoir quand même une sacré expertise), faut payer les locaux, les machines (et surtout le fait que les machines doivent pas tomber en panne pendant l'usage).
y a la préparation du cours par le formateur avant et de la salle.
# Site web en anglais...
Posté par Misc (site web personnel) . En réponse à la dépêche Appel à contributions pour le Paris Open Source Summit #OSSParis15. Évalué à 10.
Je ne peux m’empêcher de remarquer que le site web en anglais ne fait pas très sérieux :
"Systematic Paris-Region Tarsus and announce the merger salons Solutions Linux / Open Source and Open World Forum "
je suis pas traducteur, mais je pense que "Systematic Paris-Region and Tarsus announce the merge of Solution Linux / Open Source and Open World Forum". Et c'est que la première page.
Cliquer sur un lien bascule à nouveau vers du français la plupart du temps, et je trouve les tournures de phrases assez curieuses (mais techniquement correct) comme "arisen from", "associative village".
Et pareil ailleurs:
http://www.solutionslinux.fr/Conf%C3%A9rences_168.html?lg=en
- PME n'est pas traduit ( c'est SMB),
- Syndicate fait plus penser au syndicat du crime (https://en.wikipedia.org/wiki/Syndicate) et trade union serait peut être une meilleur traduction.
- ESN(?) , pourquoi un (?) traine encore ?
J'aurais bien passer le CfP a mes collègues anglophones en dehors de france, mais comme la traduction en anglais est "in progress", j'ai pas envie de passer pour un rigolo. Mais comme le CfP est ouvert que pour 3 semaines, ça va faire short. Pour quelque chose d'envergure européen, ça le fait pas.
Alors je comprends les soucis d'avoir du travail, de tenir les délais, etc, etc. Mais ça ne réhausse pas hélas ma vision de ces 2 événements combinés.
[^] # Re: patapay
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Mageia 5, la magie continue !. Évalué à 2.
Non, c'était pas un des buts de l'assoce, ni du projet. On s'est pas dit "tiens, on va faire une assoce pour que nos quelques potes fassent des thunes". Les gens de hupstream ont dit "on va monter une boite à coté parce qu'on a envie d'être à notre compte" mais c'etait pas "on va monter une boite pour faire du service".
Et de ce que je sais, Mageia est pas vraiment ce qui rapporte des affaires à Hupstream (à part via Mandriva, mais c’était pas vraiment un truc prévu). Ils font des formations, il y a eu des contrats de portages divers et variés, le fait de proposer Debian dans Azure, etc, etc.
[^] # Re: patapay
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Mageia 5, la magie continue !. Évalué à 7.
je pense du bien de Debian en tant que communauté et que projet, tout comme beaucoup de projets. C'est pas parce que je trouve un truc stupide que ça discrédite tout le reste du travail accompli par des volontaires.
Ensuite, oui, je pense la même chose de "ça sortira quand ça sera prêt", avec le bemol que Debian en tant que communauté a réalisé que c'est un souci après la sortie de Sarge, et que les paquets avec des bugs RC non corrigés sont retiré de la distribution. Ou ils ont réalisés aussi que garder des vielles archis qui bloquent la release n'est pas forcement une chose à faire.
Ensuite, globalement, comme souvent dans le libre, la méthodologie de test est assez curieuse quand on regarde de manière plus distante. Globalement, on considère que si y a pas de bugs critiques ouverts, alors c'est bon. Alors qu'on devrait plutôt à priori dire qu'un paquet ne marche pas sauf si il a été explicitement testé, avec un jeu de test pour savoir à quoi s'attendre.
Mais ça, ça impliquerais d'avoir des gens volontaires pour le faire, et pour diverses raisons, c'est pas le cas. Des raisons aussi diverses que "on ne célèbre que les codeurs/packageurs la plupart du temps".
Typiquement, ça aboutit à des choses comme "seuls les packageurs ont le droit de vote" (comme c'était le cas chez Debian avant), les packageurs ont un alias mail et pas les gens de la QA (exemple, chez mageia au début, en partie parce que la QA n'avait pas de structure du point de vue du LDAP, et parce que le souci n’était pas aussi visible pour moi que maintenant). Je ne sais pas qui fait la QA de Gnome ou KDE par exemple.
Mon taf est d'être sysadmin, je bosse sur des projets libres à aider pour l'infra, et je peux même pas te citer 3 logiciels de gestion de tests QA libre, alors que j'arrive à trouver de tête 5 bugtrackers, 3 serveurs webs, et 5 outils de gestions de configuration. Et si on voit wikipedia, c'est pas glorieux (https://en.wikipedia.org/wiki/Test_management_tools). Le tableau n'est pas complet et j'en trouve d'autres (http://www.opensourcetestmanagement.com/), mais c'est le point. C'est que c'est tellement vu comme un marché de niche par les libristes que wikipedia a moins d'informations sur ça que sur la musique country de Nashville.
[^] # Re: patapay
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Mageia 5, la magie continue !. Évalué à 6.
Alors, ça, c'est une vielle discussion. Le but de Mageia était aussi de pas jeter à la poubelle tout le travail fait par Mandriva et de mettre la communauté Mandriva aux commandes, et d'avoir son indépendance vis à vis des soucis commerciaux.
Donc rejoindre opensuse n'aurais aider sur aucun de ses 2 points (à commencer par le second).
Mais maintenant, peut être que tu penses que tout ce travail aurait du être balancé à la poubelle, et que finalement, dépendre d'une boite commercial n'était pas un objectif valable, ce qui serait ton droit, mais dans ce cas, faut le dire clairement.
[^] # Re: patapay
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Mageia 5, la magie continue !. Évalué à 8.
Alors en fait, si tu dis aux gens "Est ce qu'il faut respecter les délais", la réponse va être "Oui, bien sur". Mais la ou ça coince, c'est quand on va dire comment ça arrive que les gens le font pas.
Tout le monde est d'accord sur le fait d'augmenter la qualité, mais quand augmenter la qualité implique de virer des paquets, ça rale chez Mageia. Tout le monde est d'accord pour augmenter la qualité, mais quand ça requiert de faire plus de tests et/ou réduire la voilure, c'est pareil chez Fedora, les gens grognent.
Donc dire "c'est important" et avoir l'aval des gens de la communauté n'a vraiment d'importance que si les gens ne comprennent pas l'impact, et je pense que dans le libre comme ailleurs, les gens ne cherchent pas à avoir "the big picture".
Le but n'est pas de critiquer le processus ou les personnes, sinon, j'aurais donné des noms, pour commencer, si le but était de faire porter le chapeau à quelqu'un.
Le but est de montrer que l'état d'esprit "on sort quand c'est prêt" a des ramifications profondes.
Mais les gens implicitement semblent opposer la qualité et les délais, cf le message qui a commencé ce thread, cf toi même plus haut en parlant de dosage entre les 2, et cf la tonne d'exemple de debianneux qui ont le même avis.
C'est une fausse dichotomie et c'est ça le souci.
Tu peux aussi avoir la qualité et tenir des délais mais il faut réduire sur un autre axe, celui des nouveautés et de la charge de travail, et faire que la qualité soit une priorité plus grande que la nouveauté (dans l'esprit de la communauté). Sauf que l'axe en question est quasiment sacré partout, et personne ne semble le remettre en cause sauf dans de rares cas. Quand un truc change l'interface des utilisateurs, alors soudainement, des gens protestent mais c'est plus un rejet qu'une réflexion poussé sur la charge de travail (comme on peut le voir notamment avec le rejet de systemd).
Par exemple, chez Fedora, il a été dit "non" au passage à gcc 5.1 mais il est quand même passé. J'ai vu moins de 1% de paquets refusé lors du version freeze chez Mageia et la seul fois ou je me souviens d'un "non", c'est quand même passé.
Tout le monde va être d'accord sur "faut de la qualité", mais personne ne veut vraiment garder à l'idée que faire des paquets n'est qu'une sous partie du travail. Par exemple
J'ai jamais eu de dédoublement de personnalité au point de me répondre à moi même, donc même au temps ou j'aurais répondu, je ne me serait pas répondu à moi même. Et tenter de faire changer les choses, j'ai déjà donné, le misc dont tu parles à largement payé le prix.
On est sur Linuxfr, l'intention première, c'est de discuter. Je ne vois autre chose dans le concept de commenter un commentaire d'une news. Si je voulais vraiment donner plus d'expositions à mes idées, je pourrais juste faire une conférence, ouvrir un blog et faire de la pub sur twitter etc. Si j'avais à coeur d'influencer le projet d'une manière direct, je connais encore le chemin vers la liste de discussion.
[^] # Re: patapay
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Mageia 5, la magie continue !. Évalué à 10.
Pas vraiment, il a juste suivi ce qui est dit sur le blog:
https://blog.mageia.org/fr/2015/06/20/mageia-5-brille-dans-firmament-libre/
Le simple fait de se dire que "tenir les délais" soit juste un "nice to have" est déjà un souci.
Par exemple, ça a des implications assez embêtantes pour publier un magazine avec, ça pose souci pour organiser un événement à l'avance, etc. Je ne verrais pas l'ubuntu party avoir autant de monde si l'équipe d'orga n'avait pas la certitude de la date de sortie par exemple.
Et contrairement à ce qu'on peut croire, avoir des délais n'est pas incompatible avec le fait d'être volontaire. Par exemple, l'organisation d'un événement (ou d'un mariage), le fait de publier un magazine (Linux mag spécial Perl/python/bsd/etc) sont autant d'exemple de choses ou une organisation de volontaire a marché, parce que le but est claire à atteindre et parce qu'on se dit pas "c'est ok d'être en retard".
Mageia 4 a été sorti à temps, c'est bien la preuve que ç'est faisable.
Mais le fait de se dire "ça arrive, on y peut rien" est sans doute une des raisons qui fait que je ne vois pas avoir de discussions ou d'annonce d'un postmortem pour voir ce qui a causé des soucis, et comment éviter ça pour le futur.
Parce que tout le monde a internalisé que c'est une bonne chose.
Pourtant, il suffit de lire le blog pour voir qu'il y a sans doute des choses à proposer et à discuter.
Par exemple, rpm 4.12 a causé des soucis au point de casser tout et de repousser le beta de facile un mois, voir plus, cf https://blog.mageia.org/fr/2014/11/12/une-longue-route/.
Il faut bien voir que si on suit le planning, le version freeze était le 9 septembre (https://wiki.mageia.org/en/Mageia_5_Development).
Rpm 4.12 est sorti le 16 septembre
(http://lwn.net/Articles/612037/).
Le premier paquet de rpm 4.12 a été poussé le 6 septembre :
http://sophie.zarb.org/distrib/Mageia/cauldron/x86_64/media/core-release/by-pkgid/9928e5fe5f5197e4234939cd11929c8f/changelog
Et au vue des commits qui ont suivi, le paquet n'était clairement pas prêt.
Donc pourquoi avoir choisi de pousser rpm au lieu de faire d'abord une recompilation à part, puis de pousser une fois qu'on voit que ça ne casse pas tout ?
Pourquoi rpm 4.12 n'est pas passé comme une feature de mageia vu son potentiel à tout foutre en l'air, vu que le processus est modélisé sur la base de celui de Fedora. (et rpm 4.12 est passé comme feature chez Fedora par exemple)
Ce processus implique notamment de détailler quoi faire si ça va pas si c'est pas prêt à temps et comment revenir en arrière sans filer un truc pas prêt.
Mais la partie "on a un plan de secours pour s'assurer que les délais sont tenus", c'est visiblement totalement secondaire. Le template des features parle de conteingency, mais en regardant sur https://wiki.mageia.org/en/Category:ProposedFeatureMageia5
J'ai trouvé 5 features avec un plan de secours.
Sur un total de 21, c'est quand même assez peu. Et encore, aucune n'a de critère d'activation du plan de secours et je parle même pas du planning, qui est visiblement un peu pris à la légère.
Donc oui, la communauté se dit que c'est pas important de tenir les délais et que personne fait rien pour permettre de les tenir.
Un autre example, les mises à jours avec urpmi vont toujours de l'avant donc du coup, une fois qu'un truc est poussé, c'est dur de revenir en arrière dans Cauldron. Il faut mettre un tag epoch, et c'est "moche", et parfois pose des emmerdes.
Mais il est possible de faire des downgrades avec rpm (yum le fait depuis des années). Donc il suffirait juste de dire à urpmi que si le paquet est plus récent sur les dépots, on mets à jour, et si il est plus vieux, on rétrograde pour Cauldron. Et une fois en freeze, on reviens au mode normal avec mise à jour uniquement, mais plus grand contrôle de ce qui rentre.
Mais personne ne bosse sur ça ou ne propose ça.
[^] # Re: patapay
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Mageia 5, la magie continue !. Évalué à 10.
Si un composant est trop problématique pour être corrigé à temps, il "suffit" de revenir en arrière avant la sortie.
Et ne pas tenir les délais a des conséquences sur le moral des gens, sur la capacité à planifier la sortie et divers autres choses. C'est pas juste "faire plaisir".
En fait non, participer ne suffit pas, et je suis bien placé pour le savoir. Ça ne suffit pas parce que le souci est structurel et tu peux pas le corriger tout seul à contre courant. Ce qu'il faut changer, c'est pas le nombre de personnes, c'est les mentalités. La majorité des packageurs ont un conditionnement pavlovien sur la mise à jour des paquets (et l'ajout de nouveaux paquets) et une obsession de la nouveauté. Et ça a des impacts énormes sur l'équilibre des équipes les unes par rapport aux autres, sur la maintenance long terme et d'autres trucs.
[^] # Re: patapay
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Mageia 5, la magie continue !. Évalué à 8.
ouais, plusieurs projets en retard chez divers clients par le passé, ou plusieurs émissions sur la gabégie des fonds publiques.
Je ne comprends que la communauté du libre se gargarise de pas savoir tenir les délais et d'être incapable d'en donner. Et l'excuse "on peut pas prévoir le travail requis" est pas moins valable pour le libre et les bénévoles que pour une boite. Dans une boite, tu peux avoir des gens qui partent, qui tombent malade et des soucis en tout genre.
C'est une chose d'avoir du retard, c'est une autre d'estimer que c'est un gage de qualité quand ça cache plus un manque de moyen.