TP2 : Analyse de projet
Pendant le TP, formez des groupes de 3. Vous allez analyser trois projets pendant le temps du TP. Pour chaque projet, procédez de la manière suivante :
Sur le Grist du cours, dans la table “projets”, ajoutez vos noms sur la ligne du projet que vous souhaitez analyser. Créez une branche avec le nom nomduprojet-analyse, où vous ajoutez le fichier nomduprojet/ANALYSIS.md.
Ce fichier devra contenir le template ci-dessous, dûment rempli.
Mettez un message de commit explicite de la forme :
1
2
3
4
5
Add information about Blender project
Co-Authored-By: Prénom Nom <prenom1.nom1@telecom-paris.fr> (avec votre email lié à votre compte gitlab)
Co-Authored-By: Prénom Nom <prenom2.nom2@telecom-paris.fr>
Co-Authored-By: Prénom Nom <prenom3.nom3@telecom-paris.fr>
Vous pouvez trouver plus d’informations sur comment rédiger des messages de commits de manière générale (pour votre projet 3TC37, mais aussi pour Artishow ou pour tout autre projet que vous pourrez avoir sur git) ici par exemple.
Une fois votre commit ajouté dans la branche, ouvrez une Merge Request avec le titre [Analyse] Nom du projet.
Le template:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
## Analyse du projet
Date et Auteur(s) du présent document : John Smith Junior & Jane Smith - 1970-01-01
| Question | Réponse |
| --- | --- |
| Langage de programmation | haskell |
| Licence (SPDX) | [EUPL-1.2](https://github.com/.../.../blob/main/LICENSE) |
| Site web | https://... |
| Dépôt officiel | https://gitlab.freedesktop.org/.../... |
| Guide de contribution éventuel | https://salsa.debian.org/.../.../blob/main/CONTRIBUTING.md |
| Code de conduite éventuel | https://framagit.org/.../.../blob/main/CODE_OF_CONDUCT.md |
| Date du dernier commit | il y a X jours / mois / années |
| Fréquence commit | 1/mois environ |
| Estimation du nombre de contributeurs réguliers | une douzaine ? |
### Principaux mainteneurs
- ...
### Organisations impliquées dans la maintenance ou le financement
- ...
### Comment sont accueillies les nouvelles contributions dans le projet, le cas échéant ?
<!-- En combien de temps quelqu'un répond aux merge requests et aux issues ? Le projet semble-t-il accueillant ? (liens vers des exemples) -->
Rendu 2
-
Faites une analyse de projet supplémentaire (quatrième) de manière individuelle sur le projet de votre choix (pas encore analysé).
-
Approuvez deux MR d’analyses de projet dans lesquelles vous n’êtes pas impliqué. Pensez à vérifier les informations ainsi que la forme du commit (consignes) avant d’approuver.
-
Ajouter les informations suivantes sur 2 projets de langages différents dans un troisième fichier markdown nommé
nomduprojet/DEVELOPMENT.md(se signaler dans la colonne idoine du Grist, nouvelle branchenomduprojet-development, nouvelle MR[DEVELOPMENT] Nom du projet). -
Si vous rencontrez des difficultés, vous pouvez commiter un fichier partiel et le signaler dans la MR en préfixant son nom de
Draft:. Vous pouvez ouvrir une issue pointant vers cette MR pour demander de l’aide de vos camarades (ou de nous), en y expliquant votre problème.
Template :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
## Développement
Date et auteur du présent document : 1970-01-01, Alice Doe
### Liens vers la doc
<!-- Tous liens pertinents vers de la documentation supplémentaire interne au projet (comment compiler, comment modifier le code, etc.) avec quelques explications de ce qu'on peut y trouver -->
Informations pour développeurs :
- [INSTALL.md](https://gitlab.inria.fr/.../.../blob/main/INSTALL.md)
- ...
### Processus d'installation **depuis les sources** et retour d'expérience
<!-- Toutes informations supplémentaires **manquant dans la documentation du projet**, ou toutes clarifications utiles de la documentation, qui vous auront permis de parvenir à :
Installer les dépendances nécessaires
Compiler le projet (si besoin)
Exécuter le programme résultant
Lancer les tests
Toute indication concernant des tests qui échoueraient et pour quelles raisons.
Se repérer dans la base de code. -->
### Réponses aux questions sur la base de code
<!-- Si existantes, indiquez pour chaque question si vous avez essayé d'y répondre et la réponse, si vous l'avez trouvée -->
### Une modification faite dans le code qui modifie le comportement (observable) du programme
<!-- On présentera la modification sous la forme d'un git diff : -->
```diff
diff --git a/clib/option.ml b/clib/option.ml
index 2a6244dc56..1475b417b9 100644
--- a/clib/option.ml
+++ b/clib/option.ml
@@ -18,8 +18,8 @@
(** [has_some x] is [true] if [x] is of the form [Some y] and [false]
otherwise. *)
let has_some = function
- | None -> false
- | _ -> true
+ | None -> true
+ | _ -> false
let is_empty = function
| None -> true
```
<!-- indiquer le comportement changé et comment vous l'avez observé -->
<!-- si utile, compléter par une capture d'écran -->
### Une modification dans le code du programme qui conduit à faire échouer un ou plusieurs tests qui passaient précédemment
<!-- idem que précédemment -->
<!-- inclure un extrait du log des tests avant / après la modification -->