2) La seconde partie qui détaille les "grosses" nouveautés doit-elle être ullifiée ou pas ? Est-elle trop longue, pas assez longue, trop technique, pas assez technique, etc ?
Non. Elle est bien comme ça, pas besoin d'unifier ou de faire des parties et sous parties je pense. Quand au niveau technique je pense aussi que c'est suffisant, ceux qui voudront aller plus loin peuvent cliquer sur les liens des articles Lwn.
3) Il y a beaucoup de d'hyperliens dans ces dépêches sur le noyau (une centaine dans celle-ci). Est-ce que vous cliquez sur ces liens ou pas ? Si oui sur combien en moyenne ? Est-ce qu'il y en a trop ou non ?
Selon moi c'est très bien comme ça. D'autant qu'il y a beaucoup de référence à Lwn, ce qui me semble être la source la plus judicieuse.
5) Est-ce que vous avez des idées pour améliorer ces dépêches sur le noyau ?
Oui.
Tu évoques bien les évènements les plus importants du cycle (Btrfs, etc...) mais ça manque de petites épices croustillantes. J'entends par là des événements qui sont majoritairement évoqués sur LKML et un peu Lwn mais qui tendent à passer à la trappe lors des annonces de sorties de version.
Par exemple un changement qui, selon moi est majeur, c'est le travail qui a été effectué sur les mutex par Peter Zijlstra en début de cycle (un poil avant la sortie de -rc1). Les mutex ont maintenant un comportement heutistique: tantôt ils drement, tantôt ils se prennent pour des spinlocks en bouclant si l'actuel possesseur du verrou est bien en train de s'executer sur un autre processeur. Si le possesseur du verrou change ou s'il est en train de dormir, alors celui qui requiert le verrou va pioncer.
Ca a beaucoup amélioré les performances. dans certains cas. Cette idée vient de la branche -rt.
Il y a plein de petit événements comme ça, comme l'exhumation du patch -rt, les irqs threadées soumises pour la branche principale et qui ont de grandes chances d'être mergée pour 2.6.30, ce qui est un énorme pas en avant pour la branche -rt (en partie).
Bref, il manque quelques petits trucs comme ça.
Bon en même temps c'est difficile de tout prendre en compte, j'admets :-)
[^] # Re: Petites questions
Posté par fweisbec . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 8.
Non. Elle est bien comme ça, pas besoin d'unifier ou de faire des parties et sous parties je pense. Quand au niveau technique je pense aussi que c'est suffisant, ceux qui voudront aller plus loin peuvent cliquer sur les liens des articles Lwn.
3) Il y a beaucoup de d'hyperliens dans ces dépêches sur le noyau (une centaine dans celle-ci). Est-ce que vous cliquez sur ces liens ou pas ? Si oui sur combien en moyenne ? Est-ce qu'il y en a trop ou non ?
Selon moi c'est très bien comme ça. D'autant qu'il y a beaucoup de référence à Lwn, ce qui me semble être la source la plus judicieuse.
5) Est-ce que vous avez des idées pour améliorer ces dépêches sur le noyau ?
Oui.
Tu évoques bien les évènements les plus importants du cycle (Btrfs, etc...) mais ça manque de petites épices croustillantes. J'entends par là des événements qui sont majoritairement évoqués sur LKML et un peu Lwn mais qui tendent à passer à la trappe lors des annonces de sorties de version.
Par exemple un changement qui, selon moi est majeur, c'est le travail qui a été effectué sur les mutex par Peter Zijlstra en début de cycle (un poil avant la sortie de -rc1). Les mutex ont maintenant un comportement heutistique: tantôt ils drement, tantôt ils se prennent pour des spinlocks en bouclant si l'actuel possesseur du verrou est bien en train de s'executer sur un autre processeur. Si le possesseur du verrou change ou s'il est en train de dormir, alors celui qui requiert le verrou va pioncer.
Ca a beaucoup amélioré les performances. dans certains cas. Cette idée vient de la branche -rt.
Il y a plein de petit événements comme ça, comme l'exhumation du patch -rt, les irqs threadées soumises pour la branche principale et qui ont de grandes chances d'être mergée pour 2.6.30, ce qui est un énorme pas en avant pour la branche -rt (en partie).
Bref, il manque quelques petits trucs comme ça.
Bon en même temps c'est difficile de tout prendre en compte, j'admets :-)