Journal Logiciel libre ou communautaire : Ma définition.

Posté par (page perso) .
Tags : aucun
0
21
déc.
2007
Beaucoup d'entre nous préfèrent utiliser du logiciel « Libre ».
Je suis moi même développeur depuis plusieurs années.
Certains prétendent que c'est grâce aux quatre libertés, garanties par la GPL.

Mais pour moi ces 4 libertés sont nécessaire, mais pas suffisante.

Voici les conditions qui me font aimer un logiciel libre :

  1. Le code source soit être disponible depuis le gestionnaire de version (svn, git, ...). La dernière version de développement et l'historique doivent être accessible au public.

  2. Il doit être facile de faire accepter une modification dans la branche principale. L'accès en écriture dans le dépôts principale doit être donné facilement.

  3. Il doit être facile de joindre les développeurs actif (par mail, jabber, irc). Et ceux-ci doivent être sympa et ouvert.


Ces conditions sont nécessaires pour que le développement soit agréable.

Le projet KDE est typiquement un bon exemple de ce style de développement.
Un compte SVN est donné sur simple demande, et permet de commiter dans toutes les applications ou bibliothèques du projet. Pas de long processus de review ou de karma. (Biensûr les débutants feront relire leur patches par les développeurs confirmés.)
Toutes les discutions se font en public.
Et en plus les développeurs sont en général sympa et accueillants.
Pratiquement personne n'est payé pour programmer sur KDE.

Tout cela fait de KDE un projet très libre et ouvert pour lequel il est agréable de participé sur son temps libre.

Évidemment, KDE n'as pas les impératifs de qualité qu'aurais un logiciel développé par une entreprise.
Mais l'ouverture et la facilité de développement et les choix techniques libre en font tout de même un excellent produit de qualité.
  • # Libre != Communautaire

    Posté par (page perso) . Évalué à 3.

    Mouais, je ne comprend pas trop où tu veux en venir avec ton speech.
    Tu veux forcer les gens à être sympa avec toi, te donner les clés de chez eux comme toi tu l'entends?
    Bof, je ne vois pas le rapport avec le libre.

    Ce que tu veux imposer (ou un autre verbe, car je ne vois pas à quoi tu veux en venir) est personnel, lié à la mentalité des gens, à leur volonté de faire un projet communautaire.

    Et je ne vois pas pourquoi on devrait limiter le libre au libre communautaire, si MS file un produit sous GPL, il me convient aussi, même si MS n'est pas sympa, même sans SVN. Le tout est que ce que j'utilise (distribué) soit libre. Le reste est du bonus, suivant ta perception des choses.
    • [^] # Re: Libre != Communautaire

      Posté par . Évalué à 1.

      Eh oui, camarade, pour arriver au communisme réel, il faut d'abord passer par une phase de dictature du prolétariat...

      Pffiou fait froid dehors, dans les rues de Moscou !
    • [^] # Re: Libre != Communautaire

      Posté par (page perso) . Évalué à 2.

      >si MS file un produit sous GPL, il me convient aussi, même si MS n'est
      > pas sympa, même sans SVN.


      Moi il ne me conviendra pas car je ne pourrais pas «participer» facilement.
      Elle est là la différence.

      À quoi te sert le libre sinon ? À pouvoir dire « supaire j'ai les sources » ?
      Car si tout le monde doit maintenir un fork pour chaque petite modification, ça va pas aller.

      Et donner un accès au SVN ne signifie pas donner les clef[1]. En cas d'abus, il est facile de faire un revert. (Et en pratique j'ai jamais vu d'abus)

      [1] Ou de laisser sa voiture ouverte ;-) (pour ceux qui suivent)
      • [^] # Re: Libre != Communautaire

        Posté par . Évalué à 2.

        Linux ne fonctionne pas du tout comme ça. Mais plutot avec une pyramide de responsable de morceau de code.

        "La première sécurité est la liberté"

      • [^] # Re: Libre != Communautaire

        Posté par . Évalué à 2.

        Car si tout le monde doit maintenir un fork pour chaque petite modification, ça va pas aller.


        Tu vas adorer l'AGPL toi :)
        • [^] # Re: Libre != Communautaire

          Posté par (page perso) . Évalué à 2.

          Oui j'aime bien.
          Mais je vois pas le rapport.
          • [^] # Re: Libre != Communautaire

            Posté par . Évalué à 2.

            Mais je vois pas le rapport.


            Non, mais c'est pas grave... c'est vrai qu'entre maintenir son fork en interne et devoir en plus le publier (ce qui est un cas fréquent avec l'AGPL), il n'y a pas des masses de différences...
            • [^] # Re: Libre != Communautaire

              Posté par (page perso) . Évalué à 2.

              L'AGPL tout comme la GPL n'est qu'une licence.
              Et il est toujours possible de respecter une licence à la lettre sans en respecter l'esprit.

              L'esprit de l'AGPL est que si je fais des modifications, je dois les fournir.
              • [^] # Re: Libre != Communautaire

                Posté par (page perso) . Évalué à 2.

                L'esprit de l'AGPL est que si je fais des modifications, je dois les fournir.

                Faut arréter de dire des conneries... On dirait le FUD classique contre la GPL!
                Si tu fais des modifications est que tu diffuses la version modifiée, tu dois fournir le source de la modification aux clients qui utilisent ton site web.
                * Si tu l'utilises juste pour toi, tu ne dois rien redistribuer
                * Si tu l'utilises sur l'intranet de l'entreprise, tu dois fournir le code source aux employés de l'entreprise qui utilisent ton soft.
                * Les gens qui ne touchent pas à ton soft (99.999% de la population mondiale quand même) n'ont aucun droit de te demander tes modifs.

                L'esprit de l'AGPL est le même que la GPL, la seule (grande) différence est la notion de distribution, qui dans le cas le l'AGPL est la personne qui accède au site.
                • [^] # Re: Libre != Communautaire

                  Posté par . Évalué à 2.

                  Si tu l'utilises sur l'intranet de l'entreprise, tu dois fournir le code source aux employés de l'entreprise qui utilisent ton soft.


                  Ben ça aussi c'est une affirmation avec des relents de fud Microsoft... Si tu utilises une application AGPL dans ton entreprise et que les employés y accèdent dans le cadre de leur activité professionnelle, c'est une seule et même personne morale qui utilise l'application, et il est peu probable que l'obligation de redistribuer soit applicable dans ce cas.

                  L'esprit de l'AGPL est une caricature de l'esprit de la licence GPL, une forme exagérée ou on renforce les devoirs et où on réduit les droits de la personne ayant fait le choix d'utiliser l'application au profit de celle ayant décidé d'utiliser le service offert par la première...

                  L'effet de bord amusant sera la multiplication des forks.
                  • [^] # Re: Libre != Communautaire

                    Posté par (page perso) . Évalué à 2.

                    Pour la personne morale, je n'irait pas plus car pas sûr ni dans un sens, ni dans l'autre, mais ce passage :
                    L'effet de bord amusant sera la multiplication des forks.

                    est trop gros.
                    Qu'est-ce que l'AGPL change par rapport à la GPL pour les forks? Rien.
                    Tout le monde a accès au code de Linux sous GPL, plein de monde se fait refouler, ça ne motive pas les forks.
                    l'AGPL ne fait que rendre plus redistribuable le source, je ne vois pas ce qui te permet de dire que ça permet d'augmenter les forks.
                    Les forks, par definition, sont plutôt limités au nombre de personnes motivées pour maintenir un truc à coté, pas une différence licence BSD/LGPL/GPL/AGPL/Toute licence libre que tu souhaites.
                    • [^] # Re: Libre != Communautaire

                      Posté par . Évalué à 2.

                      Qu'est-ce que l'AGPL change par rapport à la GPL pour les forks?


                      vu que l'AGPL oblige à publier ses modifications (dans le cas ô combien rarissime où on les utilise sur internet), ça va dans les faits pousser chaque utilisateur ayant fait une modif à mettre à disposition sa propre cuvée... rapidement, on va se retrouver avec des dizaines de versions pas tout à fait équivalentes de chaque application AGPL, avec des écarts de version par rapport au code de base, des changements rendant incompatibles, ...

                      le risque est de se retrouver avec une jungle maintenue à bout de bras par des gens pas forcément motivés.
                      • [^] # Re: Libre != Communautaire

                        Posté par (page perso) . Évalué à 2.

                        tu veux dire que ça va obliger à travailler plus proprement et soumettre ses changements upstream au préalable pour bénéficier de nouvelles fonctionnalités sympathiques, qui bénéficieront ainsi à tout le monde ?

                        Un bon point pour l'AGPL donc ;-)
                        • [^] # Re: Libre != Communautaire

                          Posté par . Évalué à 2.

                          c'est vrai que c'est la période de nöel, tout les espoirs sont permis
                        • [^] # Re: Libre != Communautaire

                          Posté par . Évalué à 2.

                          tu veux dire que ça va obliger à travailler plus proprement et soumettre ses changements upstream au préalable pour bénéficier de nouvelles fonctionnalités sympathiques, qui bénéficieront ainsi à tout le monde ?


                          Drôle mais peu réaliste...

                          Dans la majorité des cas, les utilisateurs contraints de devenir distributeurs vont le faire en se foutant de la qualité de ce qu'ils redistribuent. L'AGPL va forcer la redistribution, pas la qualité, pas la méthodologie.

                          Et si en upstream une modif n'est pas intégrée, ça fera effectivement et irrémédiablement un fork (parce que l'utilisateur en bas qui a besoin d'une fonction/modif, même légère, ne va pas attendre qu'on réagisse en haut)

                          Le libre, ce n'est pas modifier une application, renvoyer ses modifs et attendre la bénédiction de l'auteur et l'intégration dans le code "canonique" pour les utiliser.
                          • [^] # Re: Libre != Communautaire

                            Posté par . Évalué à 2.

                            de toute façon, l'utilisateur qui modifiait le logiciel le modifiait à chaque fois qu'il l'installait (ou faisait une mise à jour), il va continuer comme avant, je ne vois pas en quoi ça va multiplier les forks, l'utilisateur va continuer à le modifier à chaque fois mais va en plus rendre accessible à qui veut ses modifications. S'il ne les proposait pas upstream avant (parce qu'il voulait juste changer la couleur pour l'adapter au reste du site par exemple), il pourra très bien continuer à faire comme avant.
                            • [^] # Re: Libre != Communautaire

                              Posté par . Évalué à 2.

                              l'utilisateur va continuer à le modifier à chaque fois mais va en plus rendre accessible à qui veut ses modifications


                              Ou il va camper sur sa version en ne backportant que les éléments qu'il juge important en provenance des nouvelles versions...

                              A la longue il va s'éloigner de l'original et ses modifs seront de moins en moins faciles à intégrer dans la version "officielle"
                              • [^] # Re: Libre != Communautaire

                                Posté par . Évalué à 1.

                                Donc selon toi, quand les mêmes personnes font exactement la même chose au détail près qu'ils ne publient même pas leur modifications (integration, backport, whatever), c'est mieux ?
                                J'ai du mal à suivre.
                                Les forks, ils sont là de fait de toute façon. Je préfère qu'ils soient publiés, même si je n'irai pas jusqu'à dire qu'il est scandaleux qu'ils ne le soient pas.
                                • [^] # Re: Libre != Communautaire

                                  Posté par . Évalué à 2.

                                  Donc selon toi, quand les mêmes personnes font exactement la même chose au détail près qu'ils ne publient même pas leur modifications (integration, backport, whatever), c'est mieux ?


                                  Je dis juste, qu'en forçant la redistribution des forks "privés", on va peut-être récupérer des choses intéressantes, mais on va singulièrement détériorer le rapport signal/bruit.

                                  Pour ma part, je ne suis pas absolument contre l'idée de forcer à un moment donné la redistribution du code, mais à forcer la redistribution de tout et n'importe quoi, on va se retrouver avec tout et n'importe quoi.
                                  • [^] # Re: Libre != Communautaire

                                    Posté par . Évalué à 1.

                                    Non, ça n'ajoute aucun "bruit" au signal.

                                    Je prends l'exemple de Flock, qui est plus ou moins un fork de Firefox (en fait pas vraiment parce qu'on garde les modifications "à part" avec des overlays pour pouvoir mettre à jour facilement la version de Firefox qu'on utilise - comme a on est toujours sur la dernière version stable).

                                    Flock est un logiciel libre, sous licence GPL, et le SVN est publique. Par contre, on soumet des patchs à Mozilla quand on modifie du code qui touche au cœur de Firefox et peut lui être bénéfique.

                                    En bref, le fait que le SVN de Flock soit publique n'ajoute aucun bruit : personne n'est forcé d'aller lire le code de Flock, et ça ne nous empêche pas d'envoyer des patches upstream.
                          • [^] # Re: Libre != Communautaire

                            Posté par (page perso) . Évalué à 2.

                            C'est pareil avec la GPL.

                            Beaucoup de distributions modifient certains logiciel sous licence GPL et fournissent leurs modification.
                            Et en pratique cela ne crée pas vraiment de fork.
      • [^] # Re: Libre != Communautaire

        Posté par (page perso) . Évalué à 2.

        Car si tout le monde doit maintenir un fork pour chaque petite modification, ça va pas aller.


        Dans ce cas là, faudrait pas attendre longtemps avant qu'un "gros" fork plus sympa et ouvert prenne le relai et s'attire les contributeurs. Voire l'affaire Mambo/Joomla ou xfree/xorg
        Si Microsoft ou un autre distribue du libre avec un cadre contributif trop contraignant, c'est naturellement ce qui va se passer, les sources étant dispos.
      • [^] # Re: Libre != Communautaire

        Posté par (page perso) . Évalué à 2.

        Moi il ne me conviendra pas car je ne pourrais pas «participer» facilement.
        Elle est là la différence.

        Je vais résumer ton journal alors : tu n'aimes pas les logiciels libres (tu les classes dans la même case qu'un logiciel propriétaire à source ouverte ou pas), tu aimes les logiciels communautaires.
        Chacun est libre (sic :) ) d'aimer ce qu'il veut, mais moi j'aime tout ce qui est libre, na!
  • # C'est vendredi

    Posté par (page perso) . Évalué à 6.

    >>> Un compte SVN est donné sur simple demande, et permet de commiter dans toutes les applications ou bibliothèques du projet.

    Ce qui explique les 12 milliards d'options de chaque application de KDE et leur ergonomie "particulière".
  • # Et la BSD c'est du poulet ?

    Posté par (page perso) . Évalué à 0.

    Les licences comme la BSD qui ne garanti seulement que le code actuel est libre c'est donc pas libre !

    Et la sainte GNU/GPL n'est pas libre !!!

    RMS est un menteur !!!

    ps : vendredi tout est permis !
    • [^] # Re: Et la BSD c'est du poulet ?

      Posté par (page perso) . Évalué à 2.

      Je n'ai pas dit qu'un logiciel était libre ou pas.
      J'ai donné des condition pour qu'il soit agréable de contribuer.

      • [^] # Re: Et la BSD c'est du poulet ?

        Posté par (page perso) . Évalué à 3.

        Faudra que tu donnes ta définition du mot "définition"...

        « Logiciel libre [...] : Ma définition. »

        (Comment ça je ne lis que ce que je veux bien lire ?)
    • [^] # Re: Et la BSD c'est du poulet ?

      Posté par . Évalué à 2.

      BSD ça me fait penser à OpenBSD, par exemple, imaginez que le responsable du projet accepte tous les codes de n'importe quel amateur voulant rajouter son petit truc. Le projet serait mort depuis longtemps ou aurait perdu tout son intéret.
      Chaque projet doit voir son mode de développement étudié en fonction de son chef de projet, de ses objectifs (sécurité dans mon exemple), et de ses contributeurs.

      "Et ceux-ci doivent être sympa et ouvert"
      Je ne suis pas d'accord, il faudrait plutôt qu'ils mettent des super stripteaseuses qu'on pourrait rencontrer pour discuter du projet.
      Nan mais sérieux, chacun à sa personnalité et il faut faire avec, déjà travailler dans le logiciel libre, c'est une bonne marque de qualité.
  • # Pas le point 2

    Posté par (page perso) . Évalué à 3.

    Autant je suis d'accord avec toi que le point 1 et 3 peuvent rendre agréable le développement, autant je ne suis absolument pas d'accord avec toi sur le point 2.

    Ce n'est pas parce qu'on ne donne pas les clés à tout le monde au dépôt de source que le projet est moins communautaire. Très franchement, je préfère qu'une certaine confiance s'instaure entre les dirigeants d'un projet, et un contributeur, avant de lui donner les clés. Pourquoi ?

    - parce que même si on peut annuler des modifs, c'est franchement une perte de temps que de corriger les merdes de contributeurs peu scrupuleux, codant comme des porcs, ou tout simplement débutant. Et dieu sait si le temps nous est particulièrement précieux.

    - J'ai pas envie, sur mes projets que les types commit n'importe quoi, des fonctionnalités dans tout les sens, des trucs qui font dévier le projet de ses objectifs, ou encore des trucs inutiles, au risque de mettre en péril le produit même : au niveau stabilité, utilisabilité etc.. (c'est du vecu)

    - Si on s'aperçoit qu'un type auquel on vient de donner l'accés, fait du mauvais boulot, c'est encore une perte de temps pour le virer (lui expliquer, tout ça...), et ce n'est jamais agréable pour les deux parties. En tout cas, c'est un risque fort de tuer l'ambiance du projet si le gars en question n'est pas content et qu'il fait des histoires parce qu'on lui a couper son accès. Éviter ce genre de problème, c'est des soucis en moins. Bref, je préfère qu'il y ait une sélection à l'entrée, plutôt que de devoir virer les gens.

    - Corollaire : Ne pas donner accès en écriture à tout le monde est un gage d'une certaine qualité, en tout cas d'une qualité du niveau de ce qu'attendent les responsables du projet.

    - Je ne vois pas franchement à quoi ça sert de livrer l'accés en écriture si il y a un outils de suivi (bugzilla ou autre) et qu'il est utilisé efficacement : n'importe qui peut faire un checkout, faire sa modif en locale, et proposer un patch dans un ticket. Où est le problème ?

    De plus, tu penses qu'un processus de review c'est long et contre-communautaire : moi je dis que l'absence de review est synonyme de code pourri (en tout cas, pourrissement à moyen et long terme, donc de plus en plus dur à maintenir). Les reviews permettent d'une part aux nouveaux venus d'apprendre par leurs erreurs, et d'autre part de faire en sorte que le code commité soit d'un niveau de qualité minimal. Par exemple, dans Mozilla, les patchs, de qui que ce soit (qu'il soit débutant sur le projet ou un vieux de la vieille), sont revues par au moins deux personnes. Et pour un projet d'une telle complexité, c'est pas du superflu.

    D'ailleurs, la revue de code est un des fondements des méthodes "agiles" de développement, et garantissent, avec les tests unitaires, d'une qualité **constante**, et en tout cas plus uniforme sur l'ensemble du projet.

    Bref, je préfère donner les clés à des contributeurs qui ont montré par leurs contributions passées, qu'ils sont sérieux, qu'ils codent pas trop mal et qu'ils sont actifs.

    Il est possible que les devs de KDE donnent accès en écriture à tous, mais je serais vraiment étonné si ils ne mettent pas des droits restreints sur certains répertoires...

    Pour conclure, non, restreindre l'accès en écriture au dépôt de source n'est pas une condition pour que le développement soit agréable. Ça n'empêche nullement de coder, de proposer des patchs. Ce qui fait qu'il est agréable de contribuer à un projet, c'est le contact que l'on a avec les devs, c'est le fait qu'il ne soit pas fait n'importe quoi sur le projet, et donc qu'il y ait des objectifs clairs et définis, qu'il y ait un minimum de serieux (sans tombé dans une atmosphère dictatoriale), que les reviewers soient "pédagogiques" genre pas dire, "ton patch il est nul", mais expliquer pourquoi ici ou là ça ne va pas, qu'est ce qu'il est préférable de faire etc. Bref, avoir l'impression qu'on apprend quelque chose, qu'on avance tous ensemble dans la même direction.


    Ah oui au fait, en utilisant des dépôts décentralisés, ton point 2 n'a pas lieu d'être... les dépôts centralisés sont has been, surtout pour les gros projets... (même si j'aime bien et j'utilise subversion :-) )
    • [^] # Re: Pas le point 2

      Posté par (page perso) . Évalué à 2.

      Ton opinion est intéressante. Et c'est pour avoir ce genre d'opinion que j'ai écrit ce journal. Merci donc :-)

      C'est la même chose que avec Wikipedia. Tout le monde peut contribuer sans exception. Et ça marche !

      Bon, dans le cas des logiciel ça risque d'être légèrement plus dangereux. C'est pour ça que avec KDE il faut quand même avoir un compte SVN. Ce serait l'équivalent sur Wikipedia s'ils interdisait les contribution d'IP.

      Le fait que tout le monde puisse participer ne veux pas dire qu'il n'y a aucune relecture. Les mainteneurs des différentes parties du code lisent bien entendu le journal des commits. Et les nouveaux envoient leur patch et questions sur la mailing list (par politesse)

      En pratique, dans KDE, il n'y a eu à ma connaissance aucun abus.[1]

      Non, il n'y a aucune restriction d'accès en écriture au code de KDE.[2]

      Si il faut des plombes pour que un patche soit « accepté » par le reste des devs, ça va pas marcher. Et ça peut arriver si on ne donne pas d'accès en écriture car les mainteneur peuvent être occupé et penser qu'un autre répondra.

      Ça marche avec Wikipedia, ça marche avec KDE, pourquoi ça marcherais pas avec le reste ?

      [1] (une fois, un développeur actif a peté un cable et a commencé à comiter n'importe quoi. C'est je pense le seul cas ou un compte cvs à l'époque à été fermé. Et ce n'était pas un nouveau contributeur)
      [2] les seules restrictions sont sur les répertoire d'admin du SVN et sur les page web.
      • [^] # Re: Pas le point 2

        Posté par (page perso) . Évalué à 2.

        Ton opinion est intéressante. Tu sembles militer activement pour qu'on ne s'enferme pas dans une société de défiance (sujet à la mode) : deux chercheurs ont récemment écrit un rapport reliant la défiance d'un peuple face à son gouvernement et a ses semblables et des pertes au niveau économique. La France ayant un très fort taux de défiance, beaucoup d'argent est perdu à penser à se protéger contre ce que pourrait faire les autres qui sont bien sur malintentionnés.
        wikipedia, la Norvège et kde seraient les preuves vivantes que faire confiance aux autres n'est pas catastrophique et qu'il est globalement plus intéressant de parier sur les bonnes intentions de la majorité que de se surprotéger contre les mauvaises intentions d'une minorité.

        À cela, on peut te rétorquer (cela a été fait plus haut) que dans le cas d'un logiciel, les bonnes volontés peuvent le faire dévier de ce qui est son but fixé par le leader du projet, mais aussi qu'en l'absence de police, les mauvaises volontés (sauvageons ou concurrents) peuvent être très virulentes soit par pure méchanceté, soit avec un but particulier. On peut faire l'analogie avec les créateurs de virus : ils ont un pouvoir de nuisance énorme et pourtant on ne leur donne pas les clefs du système, et ce qui protègerait actuellement kde serait la relative confidentialité du projet...
        • [^] # Re: Pas le point 2

          Posté par (page perso) . Évalué à 2.

          * wikipedia : il y a la police quand même, et dès que c'est polémique, il faut être inscrit, voire la page est protégée. La confiance reste relative, au départ tu n'as pas accès aux pages "sensibles". Plus Wikipedia grandit, plus cette libertée laissée doit être restreinte, sans doute une preuve que dans la vie réelle (avec des vrais sous), ça ne marcherai pas, et pas non plus sur un gros projet de type "Linux".
          - la Norvège : euh... L'avantage de la Norvège est d'avoir des très gros puits de pétrole pour la partie économique, donc bon, ce n'est pas un exemple (et en plus, ils sont très policés). Ils sont certes très démocratique, mais je ne vois pas le rapport avec ce que tu cherches à décrire.
          - kde : Tout le monde a accès au CVS? Comment ils font quand un gars veut un menu "nouveau" pour KDE4, et un autre veut l'ancien style? Ca commit en permanence? Il doit bien avoir une police... Ou alors KDE vit dans un merveuilleu monde bisounours où tout le monde est gentil et demande avant de commmiter? Je ne connais pas ce monde-la...
          • [^] # Re: Pas le point 2

            Posté par (page perso) . Évalué à 2.

            >Comment ils font quand un gars veut un menu "nouveau" pour KDE4,
            > et un autre veut l'ancien style?


            On en discute sur la mailing liste entre gens civilisés jusqu'à arriver à un consensus.

            --
            Étonnant que vous parlez de la Norvège car j'y suis justement en ce moment.
      • [^] # Re: Pas le point 2

        Posté par . Évalué à 2.

        >Ça marche avec Wikipedia, ça marche avec KDE, pourquoi ça marcherais pas avec le reste ?


        Personnellement, je trouve qu'il y a beaucoup de bugs dans wikipedia. Certes, ils se corrigent, mais il y en a toujours de nouveau. Wikipedia, c'est un peu la trunk de dev mise en prod. Heureusement, que les plantages sont pas trop graves...

        (attention, humour)
      • [^] # Re: Pas le point 2

        Posté par (page perso) . Évalué à 2.

        >Si il faut des plombes pour que un patche soit « accepté » par le reste des devs, ça va pas marcher. Et ça peut arriver si on ne donne pas d'accès en écriture car les mainteneur peuvent être occupé et penser qu'un autre répondra.

        Y a pas de raisons qu'un patch soit intégrés après des plombs. Par exemple dans Mozilla, quand tu proposes un patch, et que tu demandes une revue, elle se fait dans les quelques heures ou jours, mais pas des semaines. Et ceci parce qu'il y a des responsables, des reviewers pour telle ou telle partie de code, et que la revue de code fait partie de leurs tâches (le code de mozilla est tellement gros qu'il n'y a personne qui connait suffisement bien *tout* mozilla pour pouvoir faire les reviews de n'importe quel patch).

        bref, ton "ça va pas marcher" n'est pas vrai. Ça fonctionne dans de nombreux projets.


        >Ça marche avec Wikipedia, ça marche avec KDE

        Ouai enfin, la qualité des articles dans wikipedia est très très inégale. Et ils ne sont pas systématiquement toujours relus. Mais à la limite, on s'en fiche un peu, un mauvais article ne met pas en péril le projet. On ne peut pas en dire autant dans un projet informatique comme KDE : du mauvais code peut ajouter des trous de sécurité, des problèmes de stabilité etc... Je trouve donc ça hasardeux de comparer Wikipedia avec un projet informatique.
        • [^] # Re: Pas le point 2

          Posté par (page perso) . Évalué à 2.

          Ça peux fonctionner dans un projet comme Mozilla qui a plein de sous et probablement des gens payés pour.

          Dans un projet comme KDE ou tout le monde est volontaire, certains patches peuvent rester sans réponse. Certaines parties du code n'ont en effet pas de mainteneur officiel, ou celui ci est absent ou n'as pas le temps pour répondre.

          > Je trouve donc ça hasardeux de comparer Wikipedia avec un projet informatique.

          Pourtant c'est pratiquement pareil.

          La qualité des applications ou plugins dans KDE est également inégale.
          Certaines sont très stables et d'autre moins.
          Mais c'est un peu ça le libre non ? Des applications de qualité et d'autres moins, et c'est l'utilisateur qui choisis.
          • [^] # Re: Pas le point 2

            Posté par . Évalué à 2.

            D'une part KDE a beaucoup de staff, certains d'ailleurs sont payés pour bosser sur KDE (payés par une distrib ou part Qt)

            D'autre part dans Mozilla aussi il y a des patches qui restent sans réponse pendant longtemps (il faut savoir "pinguer" la bonne personne sur IRC). Mais a mon avis ça vaut mieux que du code pourri committe sans que personne ne remarque. Ben oui : si personne n'a le temps de faire des revues à priori, j'imagine que personne n'a le temps de faire des revues à posteriori?

            Je pense même que devoir réparer les bêtises de développeurs peu scrupuleux (genre qui hackent un truc vite fait sans réfléchir avant) doit prendre bien plus de temps que de faire des revues à priori.

            Pourtant c'est pratiquement pareil.

            Non, c'est pas pareil du tout. Ce serait pareil si, avec KDE:
            * N'importe quel utilisateur aurait la competence et la possibilité de corriger un bug en quelques secondes (editer -> [modification] -> sauver)
            * Corriger un bug dans un module ne risquait pas d'en casser un autre

            Mais c'est un peu ça le libre non ? Des applications de qualité et d'autres moins, et c'est l'utilisateur qui choisis.

            Oui enfin un projet est censé avoir une qualité assez constante. Et si un projet fait par un dev sur Sourceforge à zéro controle qualite, c'est normal, mais un projet de l'envergure de KDE se doit d'avoir un certain controle. Sinon c'est pas possible avec tant de personnes ! Mais ca m'etonne pas mal, KDE a certainement un certain niveau de controle par un nombre reduit de personnes pour chaque module.

            De plus, si comme tu dis n'importe qui peut avoir un accès CVS et committer dans tous les projets, même quelque chose comme Konqueror n'est pas d'une qualité certaine.
            • [^] # Re: Pas le point 2

              Posté par (page perso) . Évalué à 2.

              Pratiquement personne n'est payé pour travailler sur KDE.
              Certains développeurs de KDE travaillent en plus pour une distribution. Mais ce qu'il font pour KDE est sur leur temps libre. Et les employés de Trolltech sont payés pour développer Qt, et s'ils travaillent aussi sur KDE c'est également sur leur temps libre. Et en général, ces derniers participaient déjà à KDE avant d'être employés.

              > * N'importe quel utilisateur aurait la competence et la possibilité de
              > corriger un bug en quelques secondes (editer -> [modification] -> sauver)


              N'importe quel visiteur de Wikipedia n'a pas les capacités pour corriger des erreurs. Soit je visite un article sur un sujet que je ne maîtrise pas, soit je ne connais mal la langue quand je visite des Wikipedia étrangères.

              > * Corriger un bug dans un module ne risquait pas d'en casser un autre

              En général c'est le cas. Corriger un bug dans une application ne risque pas d'affecter les autres. Sauf s'il y a intégration ou que c'est une bibliothèque. Mais on peux faire l'analogie avec les portails ou les template si l'on veux vraiment.

              >De plus, si comme tu dis n'importe qui peut avoir un accès CVS et
              > committer dans tous les projets, même quelque chose comme
              > Konqueror n'est pas d'une qualité certaine.


              Et c'est également ce qu'on critique sur Wikipedia. Mais dans la pratique, je remarque que ça marche.
              Les développeurs savent en général juger leurs propre compétences et évitent de faire n'importe quoi.

              Mais il est vrai que KDE n'as pas le niveau de qualité d'un bon logiciel professionnel. Mais pourtant il s'en rapproche assez bien.
    • [^] # Re: Pas le point 2

      Posté par . Évalué à 2.

      Je préfère nettement la vision de Gof, ça me rappelle le livre de Jean-Michel Cornu et le chapitre sur la Coopération-Réciprocité-Pardon.

      http://www.cornu.eu.org/texts/cooperation
      http://fr.wikipedia.org/wiki/Coop%C3%A9ration-r%C3%A9ciproci(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.