• [^] # Re: L'upstream

    Posté par . En réponse au journal Mark Shuttleworth : il remet ça. Évalué à 5.

    > C'est pas faux, on blinde de bug report et de patch une certaine version du noyau par exemple (idem avec gnome etc.) je vois de l'aide mais pas de pression.

    Si les distributions faisaient correctement leur boulot, il n'y aurait même pas à évoquer cette idée.
    FedoraProject a fait le choix de travailler directement en upstream, tout bogue corrigé dans Fedora l'est automatiquement en upstream, c'est une politique définie au niveau du projet. Gentoo, et dans une moindre mesure Novell ont une politique semblable.
    A l'exception de quelques paquets, Ubuntu est un très mauvais élève concernant les remontées en upstream. Au bout de 4 ans, ils ont encore du mal à faire des remontées vers Debian, mais c'est encore pire pour les remontées en upstream.
    La réponse d'Ubuntu est désarmante à ce sujet: ils recommandent aux développeurs de venir suivre directement les patchs chez eux ! Vous imaginez si tout les développeurs devaient fouiller les bugzilla (et autre clones propriétaires) de toutes les distributions ? Vous imaginez le temps perdu à distinguer les patchs spécifiques à tel distribution, à corriger les patchs gruik-esque de certains empaqueteurs ? Sans compter qu'un bogue corrigé dans une distribution pourrait bénéficier à tous ?

    Hein, la meilleure façon de mutualiser les ressources c'est de travailler main dans la main avec upstream et non pas dans un rapport de force.

    Si tu es développeur d'un projet libre, tu apprécierais qu'un "metteur en boite" décide pour toi d'un calendrier sur deux ans avec des objectifs précis sans te demander ton avis ? Tu ne vois pas où est la pression dans cette proposition ?
    On te parle pas de blinder une version précise de rapports de bogues ou de patchs (faudrait déjà qu'Ubuntu s'améliore grandement en ce domaine) mais carrément d'imposer une feuille de route aux développeurs. Il parle bien de coordonner les différents projets et pas de prendre une version au pif pour la tester à mort.
    De plus, en focalisant toute la force de travail sur telle version, tu ralentiras automatiquement le développement du logiciel

    Canonical a refuse Debian Common Core qui proposait strictement la même chose au niveau des distributions dérivées de Debian. Et maintenant, il veut faire la même chose avec RHEL et SuSE deux distributions complétement différentes?

    La force du libre, c'est que chacun est libre d'innover, de casser des modules si nécessaire. Si tu imposes à un cadre trop rigide, les contributeurs se feront chier comme des rats morts, ça n'avancera plus.
    Les distributions n'ont pas forcément les mêmes objectifs, si la proposition de Shuttleworth aait été mise en application:
    * pas de gvfs et de PA car on ne casse plus rien à l'approche de la release. Bref, on se coltine des merdes comme Gnome-vfs et ESD pour des années de plus.
    * Fedora 9 (base de RHEL 6) n'aurait pas été libre de travailler pour linux 2.6.25 et xserver 1.5 pour privilégier les versions "sélectionnés", retardant d'autant le développement de ces logiciels. Le développement de NetworkManager 0.7 aurait été abandonné pour maintenir la version "stable" alors que c'est une impasse. Brisant le contrat entre Fedora et la communauté qui consiste à faire avancer le logiciel libre.
    * Debian devrait sortir une version qui ne correspond pas à ses propres critères de qualité.
    Au final, ça reviendrait aux autres distributions de caler leurs objectifs sur ceux d'Ubuntu au détriment de leurs siens. Je ne crois pas que le logiciel libre y soit gagnant.


    > une distrib en général on est fidèle, on la garde des années, non ?
    Quel est le rapport avec la discussion ?