Changes between Version 16 and Version 18 of FaQ


Ignore:
Timestamp:
Aug 20, 2006, 2:08:33 PM (13 years ago)
Author:
anonymous
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FaQ

    v16 v18  
     1
    12= fr-Questions fréquentes =
    23
    34== Q: Que devient spip-contrib ? ==
    45
    5 R: [http://www.spip-contrib.net/ SPIP Contrib] reste le site qu'on connaît, il propose des contribs, des trucs des astuces, des bout de docs, un peu de tout quoi . Par contre les "grosses" contribs ou les contribs qui gagneraient à bénéficier d'un système d'archivage tel que trac et donc d'un travail communautaire passe sous trac.
     6R: [http://www.spip-contrib.net/ SPIP Contrib] reste le site qu'on connaît, il propose des contribs, des trucs des astuces, des bout de docs, un peu de tout quoi . Par contre les "grosses" contribs ou les contribs qui gagneraient à bénéficier d'un système d'archivage tel que trac et donc d'un travail communautaire passe sous trac.
    67
    78== Q: Que devient spip-lab ? ==
     
    1314R: Il faut postuler auprès de l'équipe des commiters, qui prendra en compte les critères suivants :
    1415 * les besoins courants de recrutement (inutile d'être trop nombreux)
    15  * le fait d'avoir "fait ses preuves" dans la communauté, sur spip-contrib ou sur spip-dev par exemple
     16 * le fait d'avoir "fait ses preuves" dans la communauté, sur spip-contrib ou sur spip-dev par exemple
    1617 * le caractère désintéressé de la démarche
    1718 * l'absence d'incompatibilité de toute nature
     
    4041Les règles peuvent aller d'une extrême liberté à une extrême besoin de contrôle. Par exemple :
    4142
    42  1. Règle ultralibérale : « chacun fait ce qu'il veut dans cette branche. Ajouter, modifier, effacer. » (sur une zone "bac à sable").
     43 1. Règle ultralibérale : « chacun fait ce qu'il veut dans cette branche. Ajouter, modifier, effacer. » (sur une zone "bac à sable").
    4344
    4445 1. Règle ouverture maximum dans le cadre d'un projet précis : « chacun est libre d'*améliorer* ce projet en intervenant directement ; en cas de doute écrire aux responsables de la branche : toto@dupon.org, gir@blob.net »
    4546
    46  1. Règle "contrôle strict" : « nul ne peut intervenir sur les fichiers de cette branche sans avoir au préalable envoyé un patch au format diff -pu aux responsables de la branche, et reçu de l'un d'eux un "OK" formel. »
     47 1. Règle "contrôle strict" : « nul ne peut intervenir sur les fichiers de cette branche sans avoir au préalable envoyé un patch au format diff -pu aux responsables de la branche, et reçu de l'un d'eux un "OK" formel. »
    4748
    48  1. Règle "ad hoc" : « améliorez les CSS comme vous voulez, mais que personne ne touche au code, zerc@lili.il est la seule à modifier du code sur cette branche (envoyez-lui vos propositions de patches, elle les intégrera) ; en ce qui concerne les fichiers extension_xxx.php, en revanche, n'hésitez pas à les modifier ou en ajouter, sans demander d'autorisation préalable. »
     49 1. Règle "ad hoc" : « améliorez les CSS comme vous voulez, mais que personne ne touche au code, zerc@lili.il est la seule à modifier du code sur cette branche (envoyez-lui vos propositions de patches, elle les intégrera) ; en ce qui concerne les fichiers extension_xxx.php, en revanche, n'hésitez pas à les modifier ou en ajouter, sans demander d'autorisation préalable. »
    4950
    5051Etc. Si un ensemble de règles émergent, on essaiera de penser à les formaliser un peu, histoire de ne pas avoir un casse-tête impossible :)
    5152
    52 Remarque : Il est techniquement possible, avec subversion, d'installer un script qui vérifie qu'un "commit" est conforme à telle ou telle règle binaire, du genre "untel peut commiter ici mais pas là". Mais ça n'est pas très simple à configurer (d'où un manque de "fluidité"), surtout si le script doit juger de la pertinence de telle ou telle intervention (si on peut corriger une virgule ou ajouter un commentaire, mais pas modifier la css, ou l'inverse...).
     53Remarque : Il est techniquement possible, avec subversion, d'installer un script qui vérifie qu'un "commit" est conforme à telle ou telle règle binaire, du genre "untel peut commiter ici mais pas là". Mais ça n'est pas très simple à configurer (d'où un manque de "fluidité"), surtout si le script doit juger de la pertinence de telle ou telle intervention (si on peut corriger une virgule ou ajouter un commentaire, mais pas modifier la css, ou l'inverse...).
    5354
    5455Mais si l'on ne réussit pas à se coordonner avec ce système de règles d'intervention, ce n'est pas une mesure technique qui permettra de sortir de l'impasse.
     
    5657== Q: Quand faut-il forker un projet ? ==
    5758
    58 R: Si, pour des raisons techniques ou esthétiques, il est impossible de faire autrement, il faut forker -- par exemple, pour changer la couleur d'un squelette, l'internationaliser ou y ajouter un module, il est en général inutile de forker... en revanche s'il s'agit de changer la nature du projet (transformer le "bouton mémo" en "outil à tout faire dans spip de l'extérieur"), il faut probablement forker.
     59R: Si, pour des raisons techniques ou esthétiques, il est impossible de faire autrement, il faut forker -- par exemple, pour changer la couleur d'un squelette, l'internationaliser ou y ajouter un module, il est en général inutile de forker... en revanche s'il s'agit de changer la nature du projet (transformer le "bouton mémo" en "outil à tout faire dans spip de l'extérieur"), il faut probablement forker.
    5960
    6061Deuxième cas, si après avoir discuté avec la personne responsable du projet, celle-ci fait la sourde oreille ou maintient sa position, il faut réfléchir aux arguments apportés :-) et ensuite pourquoi pas forker.