mgoeminne a écrit 39 commentaires

Est-il possible de connaître la nouvelle complexité avec référence en arrière?

Sinon : "l'ancien comportement peut-être conservé" => l'ancien comportement peut être conservé.

Merci pour la nouvelle, en tout cas!

1. Je ne suis le "petit gars" de personne, et je n'autorise personne à me traiter de tel.
2.

a. 'Empirical Studies of Open Source Evolution', Fernandez-Ramil, Juan and Lozano, Angela and Wermelinger, Michel and Capiluppi, Andrea, in 'Software Evolution'

b. 'Maispion: a tool for analysing and visualising open source software developer communities', Stephany, François and Mens, Tom and Gîrba, Tudor, IWST '09: Proceedings of the International Workshop on Smalltalk Technologies

c. 'Towards a Framework for Analysing and Visualizing Open Source Software Ecosystems', Goeminne, Mathieu and Mens, Tom, IWPSE-Evol '10: Proceedings of the joint international and annual ERCIM workshops on Principles of software evolution (IWPSE) and software evolution (Evol) workshops

d. 'Towards the Comparative Analysis of the Evolution of Libre Software Distributions', Doctors, Leandro and Mens, Tom, IWPSE-Evol '10: Proceedings of the joint international and annual ERCIM workshops on Principles of software evolution (IWPSE) and software evolution (Evol) workshops

e. 'What Does It Take to Develop a Million Lines of Open Source Code?', Fernandez-Ramil, Juan and Izquierdo-Cortazar, Daniel and Mens, Tom, in the 5th International Conference on Open Source Systems (OSS '09)

f. 'Visualizing feature evolution of large-scale software based on problem and modification report data', Fischer, Michael and Gall, Harald, in Journal of Software Maintenance and Evolution: Research and Practice n°16, 2004

g. 'Two case studies of open source software development: Apache and Mozilla', Mockus, Audris and Fielding, Roy T. and Herbsleb, James D., ACM Trans. Softw. Eng. Methodol N°3, vol 11, 2002.

h. 'Macro-level software evolution: a case study of a large software compilation', Gonzalez-Barahona, Jesus and Robles, Gregorio and Michlmayr, Martin and Amor, Juan and German, Daniel, in Empirical Software Engineering n° 3, vol. 14, 2009.

i. 'Evolution in Free Software Projects : A Study of Multiple Repositories', Beecher, Karl S., 2009


3. Je persiste à dire que le nombre de commits n'est pas représentatif de l'évolution de l'activité ou de la taille d'un projet logiciel (cf certaines des références citées).

4. A noter que certaines de ces publications utilisent CVSAnaly. C'est décidément un outil fort pratique quand on s'intéresse à ce genre de choses.

Supposons que la croissance a été linéaire

Supposition gratuite, d'autant plus que dans les projets libres à succès la croissance est souvent exponentielle.

Je ne sais pas si le nombre de commits est une mesure représentative des contributions mais si c'est le cas alors il semble bien que Canonical ne contribue pas du tout à la mesure de sa popularité parmi les GNU/Linuxiens.

C'est là le problème : il faudrait tenir compte du nombre de lignes ajoutée/supprimées/modifiées. Mais ça ne suffirait pas encore : il y a des lignes qui sont faciles à ajouter mais qui n'apportent pas grand chose en elles-mêmes. D'autres sont peu nombreuses mais représentent beaucoup d'efforts. En fait, il est même mieux d'avoir du code plus "élégant", à savoir qui se traduit par peu de code ayant une forte valeur ajoutée. L'ultime problème étant que la valeur ajoutée est en fin de compte difficile à quantifier.

Deux pour moi, avec prétérition.

Merci

Merci pour ces précisions et ces liens, l'avenir paraît plus prometteur maintenant!

Arf, ça confirme malheureusement ma crainte d'il y a quelques temps :/

Il est étonnant que des efforts particuliers ne soient pas entrepris dans ce domaine, quand on voit la popularité du framework.

La difficulté de parallélisation ne me semble pas être une bonne excuse : c'est certainement un effort à faire, mais il me semble que ça apporterait une plus-value. De plus, il est peut-être possible d'imaginer un système commun à tous les systèmes de paquets avec dépendances. On rejoint alors l'esprit de l'article. Enfin, je dis ça, mais il ne faudra pas compter sur moi pour le faire ^^

Pour ce qui est de suivre l'évolution de l'installation, je ne vois pas le problème : on continue à avoir des paquets à installer, des paquets installés, et des paquets en cours d'installation. Selon mon approche, ce qui pourrait changer c'est que des paquets peuvent être téléchargés pendant que d'autres sont installés. Cette partie peut être plus difficile à représenter en console (pas avec des jauges, quoi). Mais au pire on peut toujours avec un pourcentage de paquets installés, et "oublier" de représenter le téléchargement des paquets qui se fait en arrière-plan.

Le problème de l'utilisation du disque dur me semble plus complexe. Mais dans mon cas (qui n'est sûrement pas une généralité, mais qui touche encore pas mal de monde je pense), le goulot d'étranglement n'est pas tant au niveau de l'écriture sur disque que la bande passante : dans mon cas, je vois la barre de progression des téléchargements avancer à vitesse de tortue, puis l'installation proprement dite s'exécute en un éclair.

Je me dis souvent que l'installation de la plupart des paquets déjà téléchargés aurait pu se faire 6-7 fois le temps que le téléchargement soit tout à fait terminé.

Je me suis toujours demandé pourquoi tous les paquets (ceux vraiment souhaités et leurs dépendances) étaient téléchargés puis installés en un bloc.

Je m'explique : on souhaite installer un ensemble de paquets. Ces paquets ont un ensemble de dépendances. Ces dépendances étant elles-même des paquets, elles peuvent avoir leurs propres dépendances, etc. Au final, on se retrouve avec des paquets stratifiés : les paquets dont toutes les dépendances sont présentes (ou qui n'en n'ont pas) permettent d'installer les paquets qui dépendent d'eux.

Il en résulte qu'il est possible de commencer par récupérer localement une partie choisie des paquets voulus (appelons ça une vague), et de les installer pendant que la récupération des paquets dépendant des premiers commence. Cette approche a l'avantage de ne pas faire dormir le processeur pendant le téléchargement, et de ne pas négliger la bande passante pendant que le processeur (et autres périphériques) moulinent pour installer les paquets. Donc on gagne du temps, et pour peu que l'installation de chaque vague de paquets se déroule correctement, les dépendances sont respectées. Si l'installation d'une vague échoue, seuls les paquets dépendant des paquets de la vague seront impactés.

A ma connaissance, aucun outil ne propose ça. Y a-t-il des pistes dans ce sens?

A remarquer un problème (déjà rapporté) avec Eclipse et Java : quand on développe en Java sous Eclipse, l'application se ferme spontanément. En fait, il s'avère qu'il s'agit d'une incompatibilité entre Eclipse et xulrunner. Pour résoudre le problème, le plus simple est d'installer une version plus récente de xulrunner sur le PPA de Mozilla, ou de carrément le désinstaller si on n'en a pas besoin.

Autant je comprends que les mainteneurs d'Ubuntu aient pu passer à côté de cette erreur bien qu'elle soit systématique, autant je ne comprends pas pourquoi il n'y a toujours pas de solution proposée : a priori changer un paquet suffit, et ça doit concerner une certaine quantité d'utilisateurs, non? D'autant plus qu'il s'agit d'une version assez stable d'après mes quelques jours d'expérience, c'est vraiment dommage.

Sinon : utiliser ces service => ces services.

Oui, après tout certains considèrent que les tests unitaires sont de la documentation, et certains disent qu'il faut absolument faire les tests avant de faire le code.

Il me semble donc intéressant d'envisager d'écrire la documentation avant d'écrire le code... C'est d'ailleurs un peu ce qu'on a fait pour Eiffel : définir la spécification complète du langage avant de l'implémenter... Et si le résultat n'est pas très populaire, je pense qu'on peut objectivement dire qu'il est d'une bonne qualité.

Dans le cadre de ma thèse, je suis amené à m'intéresser aux "entités" tournant autour des logiciels (libres, surtout), et à leur co-évolution. J'ai remarqué que ces derniers temps on avait tendance à parler de la documentation comme d'un pilier du logiciel (au même titre que le code source ou les rapports d'erreurs, par exemple), mais qu'elle était généralement négligée et surtout pas sérieusement prise en compte par les outils actuels.

Alors oui, maintenant on peut lancer un wiki/un site web/un planet en rapport avec le logiciel, mais toutes ces informations restent faiblement organisées et intégrées : on ne peut pas clairement et systématiquement associer une documentation avec une fonctionnalité, par exemple. Ce n'est sans doute pas trop grave pour l'utilisateur final, mais dans le cas des logiciels libres, il doit être possible (et normalement c'est espéré) que de nouvelles personnes viennent se joindre à l'équipe de développeurs, que d'autres s'en aillent, ...Bref qu'il y ait un roulement qui oblige une transmission aussi efficace que possible de la "présentation" du projet.

Ce qui serait super, ce serait que les forges intègrent ce genre de chose. La gestion des versions de la doc y serait certes nécessaire, mais de mon point de vue pas tant pour éviter le vandalisme que pour pouvoir marquer une co-évolution entre la documentation et le reste du projet. Imaginez qu'on puisse sans se prendre la tête découvrir en une heure l'évolution du projet et son état actuel, qu'on puisse voir de manière synthétique quels sont les éléments du projet, et à quoi ils servent... Cela faciliterait certainement la vie des nouveaux (et des pas nouveaux aussi, d'ailleurs) développeurs, et l'utilisateur pourrait avoir une documentation à jour, ou à défaut il pourrait déterminer là où elle pêche.

Peut-être que placer l'écriture de la documentation à côté de l'écriture du code source ou de la traduction valoriserait mieux celle-ci, et inciterait davantage de personnes à y participer.

En dehors de tout troll, je suis très curieux de voir comment Ruby on Rails va tenir sur un site comme celui-ci.

Avez-vous déjà procédé à des tests "grandeur nature"?

A mon avis, c'est plutôt 'Twitter a publié sur son compte github' et pas Twitter.

Sinon, ça aurait été super d'avoir un peu d'information sur les nouveautés de Java qui semblent assez conséquentes, avec (entre autre) la possibilité de surcharger les opérateurs (enfin!) et un nouveau garbage collector qui sera capable de faire des balayages "légers", ce qui permet de libérer souvent de la mémoire sans avoir recours à un balayage "lourd", d'où un gain de performance.

Oui, comme MicroJava par exemple, qui se base sur la spécification PicoJava. Pour une vingtaine d'euro, on a un petit processeur RISC qui peut en plus exécuter directement du bytecode, avec des perfs similaires à celles d'un binaire 'normal'. Ca s'embarque dans les machines à café, les GPS, le chat du voisin...