Changeset 7631 in spip-zone


Ignore:
Timestamp:
Nov 28, 2006, 7:03:58 AM (12 years ago)
Author:
laurent.rieffel@…
Message:
 
File:
1 edited

Legend:

Unmodified
Added
Removed
  • _contribs_/_assistants_/spip-dreamweaver/_REGLES_DE_COMMIT.txt

    r185 r7631  
     1*
     2* Contact : mailto:laurent.rieffel@laposte.net
     3*
    14
    2 Projet : spip-dreamweaver
    3 Auteur : ^fabrice^^ - www.drop-zone-city.com
    4 Contact : contact-2 (chez) drop-zone-city.com
     5*************************
    56
    6 L'objectif (de l'auteur) est de passer la main sur ce projet
    7 tout en favorisant une certaine continuité. Si vous êtes intéressé,
    8 n'hésitez pas à le contacter.
     7Le répertoire _RACINE_ est à placer à la racine du site, il contient
     8l'ensemble des traitements sur les états du paiement electronique.
     9
     10Le répertoire _SQUELETE_ est donné à titre indicatif, a terme il faudra
     11prevoir une balise et ressortir les différents "php" qui y sont inclus...
     12
     13*************************
     14
     15Fonctionnalité de cette version 1.0 :
     16_____________________________________
     17
     18- suppression/création des tables propre à la boutique en ligne.
     19  ne necessitant pas le compte administrateur de la base de données.
     20
     21- affichage avant suppression d'un boutique, et de toutes les autres
     22  n'ayant pas abouties à l'achat, avec un delais de 24h.
    923
    1024
     25Beaucoup de choses sont à implémenter :
     26_______________________________________
    1127
    12 Voici les règles à suivre avant de commiter des modifications sur
    13 cette branche.
     28- parfaire l'affichage qui pour le moment à des "echo"
    1429
    15 A. Obligation de commenter les commits
     30- voir la possibilité de modifier l'abonnement à la newsletter
    1631
    17    Si vous envoyez des modifications, il faut toujours les commenter
    18    de façon "descriptive" et "complète" avec l'option -m ou -F du
    19    commit SVN.
     32- parfaire l'affichage du formulaire de saisie des informations
     33  (sous forme de balise)
    2034
    21    
    22    
    23    
    24 B.  Modification du code
     35- (...)
    2536
    26    1. Version stable (numéroté, par exemple : version-0.50)
    27        
    28       Aucune modification profonde du code n'est attendu pour cette version.
    29       Seules les corrections de bug sont autorisées.
    30        
    31       Tout le monde à le droit de faire des modifications.
    32        
    33       Toutefois, dans un premier temps, il est souhaitable d'avertir 
    34       l'auteur principal du projet. Il faut alors, dans le mail,
    35       envoyer un patch au format "diff -pu", donner une description
    36       défendable du bug corrigé et la manière choisit pour le corriger.
    37                
    38        
    39    2. Version de développement (version-dev)
    40        
    41       Tout le monde à le droit de faire des modifications.
    42        
    43       Toutefois, dans un premier temps, il est souhaitable d'avertir 
    44       l'auteur principal du projet. Il faut alors, dans le mail,
    45       envoyer un patch au format "diff -pu" et donner une description
    46       défendable des modifications/ajouts.
    47        
    48       En particulier, il faut bien penser à:
    49       - décrire le bug que l'on corrige,
    50         comment on a choisit de le  corriger,
    51       - décrire la modification que l'on a faite et pourquoi le
    52         nouveau code est meilleur que l'ancien (qui n'est certainement pas
    53         un code parfait de toute façon)
    54       - décrire la nouvelle fonction, ce quelle apporte à
    55         l'utilisateur, les dépendances qu'elle apporte.
    56        
    57  
    58  
    59 C. Clarté du code.
    60 
    61 Il n'y a actuellement pas de règles précises d'écriture correct du
    62 code. Il faut juste garder du code indenter (i.e indenter chaque
    63 fermeture sur une nouvelle ligne pour les gros blocs), en général,
    64 suivre la façon dont c'est fait dans les fichiers de bases.
    65 
    66 Il faut toujours mettre une chaîne de documentation quand c'est
    67 possible et quand on le peut documenter le processus/l'algorithme que
    68 l'on implémente.
    69 
Note: See TracChangeset for help on using the changeset viewer.