3. Règles de restitution

R1	Utiliser le mécanisme automatique de restitution d‘astk/agla : commande asrest [D1.02.01]. Ce mécanisme impose qu’une restitution soit autonome : le code officiel modifié par la restitution doit être capable d’exécuter les cas-tests de non régression.
R2	Un “asrest” en efface un autre : il n’y a pas de pile de restitution pour un développeur donné. Un développeur ne peut donc faire plus d’un asrest par semaine pour une version donnée du code (NEW10 ou NEW9).
R3	Une “restitution” (les sources modifiés + les sources ajoutés) ne sera effective (modification des sources officiels) qu’après la procédure de mise à jour du code faite par l’administrateur [D1.02.02 §1.2]. Cette action a leu en général le mercredi matin.
R4	Ne détruire les sources d’une restitution qu’après avoir reçu (et lu) le “mail” annonçant la mise à jour du code.
R5	Toute restitution doit être accompagnée d’un fichier d’historique (type histor d’astk) dans lequel le développeur doit lister les fiches de REX qu’il «corrige». Chacune de ces fiches doit être passée dans l’état «résolu». En passant la fiche dans l’état «résolu», il faut ajouter un dernier «post» dans le REX qui résume la fiche : demande/problème, corrections réalisées, … C’est ce dernier «post» qui sera examiné en EDA le lundi matin.
R6	Exécuter la commande «pre-eda» d’Astk avant le lundi 9H. “présenter” sa restitution en réunion d‘EDA le lundi. Apporter un transparent de son fichier historique.
R7	Penser à la validation de sa restitution : ajout/modification de cas-tests.
R8	Pour détruire un source (ou le changer de bibliothèque) voir [D1.02.02 unigest].
R9	Quand on ajoute une nouvelle unité de source. Cette unité doit contenir une ligne ‘AJOUT’ dont la syntaxe dépend du type de l’unité [D1.02.02].