- en
- Langue : fr
Écriture de votre premier correctif pour Django¶
Introduction¶
Intéressé à redonner un peu de votre temps à la communauté ? Vous avez peut-être trouvé un bogue dans Django et vous souhaiteriez le corriger, ou alors vous aimeriez ajouter une petite fonctionnalité dans Django.
La meilleure manière de réaliser ces objectifs est de contribuer à Django lui-même. Si cela peut paraître une tâche effrayante au premier abord, ce n’est finalement pas si difficile que cela. Nous allons vous accompagner tout au long de ce processus afin que vous puissiez apprendre avec un exemple.
À qui est destiné ce tutoriel ?¶
Pour ce tutoriel, il s’agit d’avoir au moins une compréhension générale de la manière dont Django fonctionne. Cela implique que vous devez être à l’aise en parcourant les tutoriaux existants sur l’écriture de votre première application Django. De plus, vous devriez bien connaître Python lui-même. Si ce n’est pas le cas, Dive Into Python est un livre en ligne fantastique (et gratuit) pour les programmeurs Python débutants.
Ceux d’entre vous qui ne sont pas familiers avec les systèmes de gestion de versions et avec Trac trouveront dans ce tutoriel et ses liens les bonnes informations pour bien démarrer. Toutefois, il serait souhaitable d’en apprendre un peu plus sur ces différents outils si vous pensez contribuer régulièrement à Django.
Mais pour la plus grande partie, ce tutoriel vise à expliquer le plus possible de choses pour qu’il puisse convenir au plus grand nombre.
Où obtenir de l’aide :
Si vous avez des problèmes en suivant ce tutoriel, vous pouvez écrire (en anglais) à django-developers ou utiliser le canal IRC #django-dev sur irc.freenode.net (ou #django-fr en français) pour discuter avec d’autres utilisateurs Django qui pourront peut-être vous aider.
Quels sont les contenus de ce tutoriel ?¶
Nous allons vous guider dans votre première contribution d’un correctif pour Django. À la fin de ce tutoriel, vous aurez acquis une compréhension basique à la fois des outils et des processus nécessaires. Plus particulièrement, nous aborderons les thèmes suivants :
installation de Git,
le téléchargement d’une copie de développement de Django,
le lancement de la suite de tests de Django,
l’écriture d’un test pour votre correctif,
l’écriture du code du correctif,
le test de votre correctif,
la génération d’un fichier correctif contenant vos modifications,
les sources d’informations supplémentaires.
Une fois le tutoriel terminé, vous pouvez consulter le reste de la documentation de Django sur la façon de contribuer. Elle contient de nombreuses informations utiles et constitue une lecture indispensable pour tout contributeur en herbe à Django. Si vous avez des questions, vous y trouverez probablement les réponses.
Installation de Git¶
Pour ce tutoriel, Git doit être installé afin de pouvoir télécharger la version actuelle de développement de Django et pour générer les fichiers correctifs contenant vos modifications.
Pour savoir si Git est installé, saisissez git sur une ligne de commande. Si vous obtenez un message vous indiquant que la commande n’a pas pu être trouvée, c’est que vous devez l’installer, voir la page de téléchargement de Git.
Si vous ne connaissez pas bien Git, vous pouvez toujours obtenir des informations sur les commandes (une fois installé) en tapant git help sur une ligne de commande.
Téléchargement d’une copie de la version de développement de Django¶
La première étape pour contribuer à Django est d’obtenir une copie de son code source. À partir de la ligne de commande, utilisez la commande cd pour vous placer dans le répertoire où vous souhaitez mettre votre copie locale de Django.
Téléchargez le dépôt du code source de Django en utilisant la commande suivante :
git clone https://github.com/django/django.git
Note
Pour ceux qui préfèrent utiliser virtualenv, vous pouvez utiliser :
pip install -e /path/to/your/local/clone/django/
(où django est le répertoire de votre copie contenant setup.py) pour lier votre copie de travail locale à un environnement virtuel. C’est une bonne option pour isoler la copie de développement de Django du reste de votre système et éviter de possibles conflits de paquets.
Retour à une révision précédente de Django¶
Pour ce tutoriel, nous allons utiliser le ticket #17549 comme étude de cas ; nous allons donc revenir en arrière dans l’historique Git de Django jusqu’au point où le correctif de ce ticket n’était pas encore appliqué. Cela nous permettra de parcourir toutes les étapes nécessaires à l’écriture de ce correctif à partir de zéro, y compris en lançant la suite de tests de Django.
Gardez à l’esprit que même si nous allons utiliser une révision plus ancienne de Django dans l’optique de ce tutoriel, vous devriez toujours utiliser la révision la plus actuelle du développement de Django lorsque vous travaillez sur le correctif réel d’un ticket !
Note
Le patch de ce ticket a été écrit par Ulrich Petri et a été appliqué à Django dans le commit ac2052ebc84c45709ab5f0f25e685bf656ce79bc. Par conséquent, nous utiliserons la révision de Django qui précède immédiatement, c’est-à-dire le commit 39f5bc7fc3a4bb43ed8a1358b17fe0521a1a63ac.
Placez-vous dans le répertoire racine de Django (celui qui contient django`, docs, tests, AUTHORS, etc.). Vous pouvez ensuite extraire l’ancienne révision de Django qui nous sera utile pour le tutoriel ci-dessous :
git checkout 39f5bc7fc3a4bb43ed8a1358b17fe0521a1a63ac
Lancement de la suite de test de Django pour la première fois¶
En contribuant à Django, il est très important que vos modifications de code n’introduisent pas de bogues dans d’autres parties de Django. Une des façons de contrôler que Django fonctionne toujours après vos modifications est de lancer la suite de tests de Django. Si tous les tests passent, il est raisonnable de penser que vous n’avez pas complètement cassé Django. Si vous n’avez encore jamais lancé la suite de tests de Django, il est recommandé de le faire une fois simplement pour vous familiariser avec ce que l’on obtient d’habitude quand tout va bien.
La suite de test peut être lancée en se plaçant (cd) dans le répertoire tests/ de Django et, si vous utilisez GNU/Linux, Mac OS X ou une autre version de Unix, lancez :
PYTHONPATH=.. python runtests.py --settings=test_sqlite
Si vous utilisez Windows, les instructions ci-dessus devraient fonctionner pour autant que vous utilisiez « Git Bash » fourni par l’installation Git par défaut. GitHub dispose d’un bon tutoriel.
Note
Si vous utilisez virtualenv, vous pouvez omettre PYTHONPATH=.. en lançant les tests. Cela indique à Python de chercher Django dans le répertoire parent de tests`. virtualenv met automatiquement votre copie de Django dans PYTHONPATH.
Maintenant prenez place et détendez-vous. La suite complète de tests Django contient plus de 4800 tests différents, ce qui peut prendre entre 5 et 15 minutes en fonction de la rapidité de votre ordinateur.
Pendant que la suite de tests de Django s’exécute, vous voyez un flux de caractères représentant le statut de chaque test exécuté. E indique qu’une erreur est survenue durant le test et F indique qu’une assertion de test a échoué. Les deux sont considérés comme des échecs. Quant à eux, x et s indiquent respectivement des échecs attendus et des tests omis volontairement. Chaque point signifie qu’un test a réussi.
Les tests omis volontairement sont typiquement dus à des bibliothèques externes manquantes et nécessaires pour exécuter ces tests ; voir Running all the tests pour une liste de dépendances. Prenez soin d’installer toute dépendance de test qui est liée aux modifications que vous appliquez (nous n’en utiliserons pas pour ce tutoriel).
Lorsque les tests sont terminés, vous devez voir apparaître un message vous informant si la suite de tests a réussi ou échoué. Comme vous n’avez encore pas modifié de code Django, toute la suite de tests devrait passer. Si vous obtenez des échecs ou des erreurs, vérifiez que vous avez bien suivi toutes les précédentes étapes. Consultez Running the unit tests pour plus d’informations.
Il faut savoir que la version « trunk » (la plus actuelle) de Django n’est pas toujours stable. Lorsque vous développez sur cette version, vous pouvez vérifier les compilations d’intégration continue de Django pour savoir si les échecs que vous obtenez sont spécifiques à votre environnement ou s’ils sont aussi présents dans les compilations officielles de Django. Si vous cliquez sur une compilation particulière, vous voyez la « matrice de configurations » qui indique les échecs précisément par version de Python et par moteur de base de données.
Note
Pour ce tutoriel et le ticket sur lequel nous travaillons, il est suffisant de tester avec SQLite. Cependant, il est possible (et parfois nécessaire) de lancer les tests en utilisant une base de données différente.
Écriture de quelques tests pour le ticket¶
Dans la majorité des cas, un correctif doit contenir des tests pour être accepté dans Django. Pour les correctifs de correction de bogue, cela implique la rédaction d’une test de régression pour s’assurer que le bogue ne soit plus réintroduit plus tard dans Django. Un test de régression doit être écrit de façon à échouer tant que le bogue est présent et à réussir lorsque le bogue a été corrigé. En ce qui concerne les correctifs contenant de nouvelles fonctionnalités, vous devrez inclure des tests qui assurent que les nouvelles fonctionnalités fonctionnent correctement. Ces tests devraient aussi échouer avant que la fonctionnalité ne soit développée, et réussir après qu’elle a été implémentée.
Une bonne manière de faire cela est d’écrire d’abord les nouveaux tests, avant de toucher au code. Ce style de développement est appelé développement piloté par les tests et peut être appliqué aussi bien à des projets complets qu’à des correctifs individuels. Après avoir écrit les tests, vous les lancez pour être sûr qu’ils échouent effectivement (puisque vous n’avez pas encore corrigé l’erreur ou ajouté la fonctionnalité). Si vos nouveaux tests n’échouent pas, vous devez les corriger jusqu’à ce qu’ils échouent. Après tout, un test de régression qui passe que le bogue soit présent ou non n’est pas très utile pour éviter que ce bogue ne réapparaisse à l’avenir.
Entrons maintenant dans le vif du sujet.
Écriture de tests pour le ticket #17549¶
Le ticket #17549 décrit la nouvelle petite fonctionnalité suivante :
Il est utile de pouvoir ouvrir l’URL d’un champ URLField ; sinon autant utiliser un CharField.
Dans le but de résoudre ce ticket, nous allons ajouter une méthode render à AdminURLFieldWidget afin d’afficher un lien cliquable au-dessus de la boîte de saisie. Cependant, avant d’effectuer ces changements, nous allons écrire quelques tests pour vérifier que notre modification fonctionne et qu’elle continue à fonctionner correctement à l’avenir.
Placez-vous dans le dossier tests/regressiontests/admin_widgets/ et ouvrez le fichier tests.py. Ajoutez le code suivant à la ligne 269, juste avant la classe AdminFileWidgetTest:
class AdminURLWidgetTest(DjangoTestCase):
def test_render(self):
w = widgets.AdminURLFieldWidget()
self.assertHTMLEqual(
conditional_escape(w.render('test', '')),
'<input class="vURLField" name="test" type="text" />'
)
self.assertHTMLEqual(
conditional_escape(w.render('test', 'http://example.com')),
'<p class="url">Currently:<a href="http://example.com">http://example.com</a><br />Change:<input class="vURLField" name="test" type="text" value="http://example.com" /></p>'
)
def test_render_idn(self):
w = widgets.AdminURLFieldWidget()
self.assertHTMLEqual(
conditional_escape(w.render('test', 'http://example-äüö.com')),
'<p class="url">Currently:<a href="http://xn--example--7za4pnc.com">http://example-äüö.com</a><br />Change:<input class="vURLField" name="test" type="text" value="http://example-äüö.com" /></p>'
)
def test_render_quoting(self):
w = widgets.AdminURLFieldWidget()
self.assertHTMLEqual(
conditional_escape(w.render('test', 'http://example.com/<sometag>some text</sometag>')),
'<p class="url">Currently:<a href="http://example.com/%3Csometag%3Esome%20text%3C/sometag%3E">http://example.com/<sometag>some text</sometag></a><br />Change:<input class="vURLField" name="test" type="text" value="http://example.com/<sometag>some text</sometag>" /></p>'
)
self.assertHTMLEqual(
conditional_escape(w.render('test', 'http://example-äüö.com/<sometag>some text</sometag>')),
'<p class="url">Currently:<a href="http://xn--example--7za4pnc.com/%3Csometag%3Esome%20text%3C/sometag%3E">http://example-äüö.com/<sometag>some text</sometag></a><br />Change:<input class="vURLField" name="test" type="text" value="http://example-äüö.com/<sometag>some text</sometag>" /></p>'
)
Les nouveaux tests vérifient si la méthode render que nous allons ajouter fonctionne correctement dans plusieurs situations différentes.
Mais cette histoire de tests semble plutôt compliquée…
Si vous n’avez jamais eu affaire à des tests précédemment, ils peuvent paraître un peu difficiles à écrire au premier abord. Heureusement, les tests sont un sujet très important en programmation, il existe donc beaucoup d’informations à leur sujet :
Une première approche conseillée dans l’écriture de tests pour Django est de parcourir la documentation Écriture et lancement de tests.
Dive Into Python (un livre en ligne gratuit pour les développeurs débutants en Python) contient une très bonne section sur l’introduction aux tests unitaires.
Après ces lectures, si vous désirez un peu plus de matière à digérer, vous pouvez toujours parcourir la documentation Python de unittest.
Lancement des nouveaux tests¶
Rappelez-vous que nous n’avons encore effectué aucune modification à AdminURLFieldWidget, ce qui fait que nos tests vont échouer. Lançons tous les tests dans le dossier model_forms_regress pour être certain que c’est vraiment ce qui va se passer. À partir de la ligne de commande, placez-vous dans le répertoire tests/ de Django et lancez :
PYTHONPATH=.. python runtests.py --settings=test_sqlite admin_widgets
Si les tests se sont déroulés correctement, vous devriez voir trois échecs correspondant aux méthodes de test que nous avons ajoutées. Si tous les tests ont réussi, vous devriez alors vérifier que vous avez bien ajouté les nouveaux tests ci-dessus dans le bon répertoire et la bonne classe.
Écriture du code pour le ticket¶
Nous allons maintenant ajouter la fonctionnalité Django décrite dans le ticket #17549.
Écriture du code pour le ticket #17549¶
Placez-vous dans le dossier django/django/contrib/admin/ et ouvrez le fichier widgets.py. Trouvez la classe AdminURLFieldWidget à la ligne 302 et ajoutez la méthode render suivante après la méthode __init__ existante :
def render(self, name, value, attrs=None):
html = super(AdminURLFieldWidget, self).render(name, value, attrs)
if value:
value = force_text(self._format_value(value))
final_attrs = {'href': mark_safe(smart_urlquote(value))}
html = format_html(
'<p class="url">{} <a {}>{}</a><br />{} {}</p>',
_('Currently:'), flatatt(final_attrs), value,
_('Change:'), html
)
return html
Vérification du succès des tests¶
Après avoir terminé de modifier Django, nous devons être sûrs que les tests précédemment écrits réussissent, afin de vérifier que le code que nous venons d’écrire fonctionne correctement. Pour lancer les tests du dossier admin_widgets, placez-vous dans le répertoire tests/ de Django et lancez :
PYTHONPATH=.. python runtests.py --settings=test_sqlite admin_widgets
Oups, heureusement que nous avons écrit ces tests ! Vous devriez toujours voir 3 échecs avec l’exception suivante :
NameError: global name 'smart_urlquote' is not defined
Nous avons oublié d’ajouter l’importation de cette méthode. Corrigez cela et ajoutez l’importation de smart_urlquote à la suite de la ligne 13 de django/contrib/admin/widgets.py, ce qui donnera :
from django.utils.html import escape, format_html, format_html_join, smart_urlquote
Relancez les tests et tout devrait réussir. Si ce n’est pas le cas, assurez-vous d’avoir bien modifié la classe AdminURLFieldWidget tel qu’indiqué ci-dessus et que vous avez copié les tests correctement.
Lancement de la suite de tests de Django pour la seconde fois¶
Après avoir vérifié que votre correctif et les tests fonctionnent correctement, il est recommandé de relancer toute la suite de tests de Django, simplement pour contrôler que vos modifications n’ont pas introduit des bogues dans d’autres parties de Django. Même si quand la suite de tests passe entièrement, ce n’est toujours pas une garantie que votre code ne contient pas d’erreurs, cela aide tout de même à révéler de nombreux bogues et régressions qui pourraient être passés inaperçus.
Pour lancer la suite complète de tests de Django, placez-vous dans le répertoire tests/ de Django et lancez :
PYTHONPATH=.. python runtests.py --settings=test_sqlite
Si vous ne constatez aucun échec, c’est bon signe. Notez que ce correctif a aussi ajouté une petite modification CSS pour mettre en forme le nouveau widget. Vous pouvez faire cette modification si vous le souhaitez, mais nous allons l’omettre par soucis de concision.
Écriture de la documentation¶
Ceci est une nouvelle fonctionnalité, elle doit donc être documentée. Ajoutez le contenu ci-après à la ligne 925 de django/docs/ref/models/fields.txt, en-dessous de la documentation existante de URLField:
.. versionadded:: 1.5
The current value of the field will be displayed as a clickable link above the
input widget.
Pour plus d’informations sur l’écriture de documentation, y compris une explication sur la signification de versionadded, consultez Writing documentation. Cette page contient aussi une explication sur la manière de produire une copie locale de la documentation afin de pouvoir prévisualiser le code HTML qui sera généré.
Création du correctif contenant les modifications¶
C’est maintenant le moment de générer un fichier correctif qui pourra être envoyé à Trac ou appliqué à une autre copie de Django. Pour jeter un œil sur le correctif, lancez la commande suivante :
git diff
L’affichage montre les différences entre votre copie actuelle de Django (incluant vos modifications) et la révision que vous avez initialement extraite précédemment dans ce tutoriel.
Pour quitter l’affichage des différences, appuyez sur la touche q pour revenir à la ligne de commande. Si le contenu du correctif vous a semblé correct, vous pouvez lancer la commande suivante pour enregistrer le fichier correctif dans votre répertoire de travail actuel :
git diff > 17549.diff
Vous devriez maintenant voir un fichier nommé 17549.diff dans le répertoire racine de Django. Ce fichier correctif contient toutes vos modifications et devrait ressembler à ceci :
diff --git a/django/contrib/admin/widgets.py b/django/contrib/admin/widgets.py
index 1e0bc2d..9e43a10 100644
--- a/django/contrib/admin/widgets.py
+++ b/django/contrib/admin/widgets.py
@@ -10,7 +10,7 @@ from django.contrib.admin.templatetags.admin_static import static
from django.core.urlresolvers import reverse
from django.forms.widgets import RadioFieldRenderer
from django.forms.util import flatatt
-from django.utils.html import escape, format_html, format_html_join
+from django.utils.html import escape, format_html, format_html_join, smart_urlquote
from django.utils.text import Truncator
from django.utils.translation import ugettext as _
from django.utils.safestring import mark_safe
@@ -306,6 +306,18 @@ class AdminURLFieldWidget(forms.TextInput):
final_attrs.update(attrs)
super(AdminURLFieldWidget, self).__init__(attrs=final_attrs)
+ def render(self, name, value, attrs=None):
+ html = super(AdminURLFieldWidget, self).render(name, value, attrs)
+ if value:
+ value = force_text(self._format_value(value))
+ final_attrs = {'href': mark_safe(smart_urlquote(value))}
+ html = format_html(
+ '<p class="url">{} <a {}>{}</a><br />{} {}</p>',
+ _('Currently:'), flatatt(final_attrs), value,
+ _('Change:'), html
+ )
+ return html
+
class AdminIntegerFieldWidget(forms.TextInput):
class_name = 'vIntegerField'
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 809d56e..d44f85f 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -922,6 +922,10 @@ Like all :class:`CharField` subclasses, :class:`URLField` takes the optional
:attr:`~CharField.max_length`argument. If you don't specify
:attr:`~CharField.max_length`, a default of 200 is used.
+.. versionadded:: 1.5
+
+The current value of the field will be displayed as a clickable link above the
+input widget.
Relationship fields
===================
diff --git a/tests/regressiontests/admin_widgets/tests.py b/tests/regressiontests/admin_widgets/tests.py
index 4b11543..94acc6d 100644
--- a/tests/regressiontests/admin_widgets/tests.py
+++ b/tests/regressiontests/admin_widgets/tests.py
@@ -265,6 +265,35 @@ class AdminSplitDateTimeWidgetTest(DjangoTestCase):
'<p class="datetime">Datum: <input value="01.12.2007" type="text" class="vDateField" name="test_0" size="10" /><br />Zeit: <input value="09:30:00" type="text" class="vTimeField" name="test_1" size="8" /></p>',
)
+class AdminURLWidgetTest(DjangoTestCase):
+ def test_render(self):
+ w = widgets.AdminURLFieldWidget()
+ self.assertHTMLEqual(
+ conditional_escape(w.render('test', '')),
+ '<input class="vURLField" name="test" type="text" />'
+ )
+ self.assertHTMLEqual(
+ conditional_escape(w.render('test', 'http://example.com')),
+ '<p class="url">Currently:<a href="http://example.com">http://example.com</a><br />Change:<input class="vURLField" name="test" type="text" value="http://example.com" /></p>'
+ )
+
+ def test_render_idn(self):
+ w = widgets.AdminURLFieldWidget()
+ self.assertHTMLEqual(
+ conditional_escape(w.render('test', 'http://example-äüö.com')),
+ '<p class="url">Currently:<a href="http://xn--example--7za4pnc.com">http://example-äüö.com</a><br />Change:<input class="vURLField" name="test" type="text" value="http://example-äüö.com" /></p>'
+ )
+
+ def test_render_quoting(self):
+ w = widgets.AdminURLFieldWidget()
+ self.assertHTMLEqual(
+ conditional_escape(w.render('test', 'http://example.com/<sometag>some text</sometag>')),
+ '<p class="url">Currently:<a href="http://example.com/%3Csometag%3Esome%20text%3C/sometag%3E">http://example.com/<sometag>some text</sometag></a><br />Change:<input class="vURLField" name="test" type="text" value="http://example.com/<sometag>some text</sometag>" /></p>'
+ )
+ self.assertHTMLEqual(
+ conditional_escape(w.render('test', 'http://example-äüö.com/<sometag>some text</sometag>')),
+ '<p class="url">Currently:<a href="http://xn--example--7za4pnc.com/%3Csometag%3Esome%20text%3C/sometag%3E">http://example-äüö.com/<sometag>some text</sometag></a><br />Change:<input class="vURLField" name="test" type="text" value="http://example-äüö.com/<sometag>some text</sometag>" /></p>'
+ )
class AdminFileWidgetTest(DjangoTestCase):
def test_render(self):
Quelle est la prochaine étape ?¶
Félicitations, vous avez produit votre tout premier correctif pour Django ! En ayant franchi cette étape avec succès, vous pouvez désormais mettre en œuvre votre nouvelle compétence en aidant à améliorer le code de Django. La production de correctifs et leur envoi dans des tickets Trac est utile ; cependant, comme nous utilisons Git, nous recommandons l’adoption d’un processus plus orienté sur Git.
Comme nous n’avons pas commité localement nos modifications, effectuez ce qui suit pour faire revenir votre branche git à un bon point de départ :
git reset --hard HEAD
git checkout master
Plus d’informations pour les nouveaux contributeurs¶
Avant de vous impliquer plus intensément dans l’écriture de correctifs pour Django, il est souhaitable de parcourir un peu plus d’informations destinées aux contributeurs :
Il est important de lire la documentation de Django sur l’appropriation de tickets et la soumission de correctifs. Cela comprend les règles de comportement sur Trac, la façon de vous assigner un ticket, le style attendu du code des correctifs et encore bien d’autres détails importants.
Les contributeurs débutants devraient aussi lire la documentation de Django pour les contributeurs débutants. Elle contient de nombreux bons conseils pour ceux d’entre nous qui débutent dans la contribution à Django.
Après cela, si vous êtes toujours avide de plus d’informations sur la contribution, vous pouvez toujours parcourir le reste de la documentation de Django sur la contribution. Elle contient plein d’informations utiles et devrait constituer votre source principale de réponses aux questions que vous vous posez.
Recherche de votre premier vrai ticket¶
Après avoir consulté une partie de ces informations, vous êtes fin prêt pour partir à la recherche d’un ticket pour lequel vous allez écrire un correctif. Commencez en priorité par les tickets marqués comme « Easy pickings » (résolution facile). Ces tickets sont souvent plus simples par nature et sont une cible idéale pour les contributeurs débutants. Lorsque vous serez à l’aise avec la contribution à Django, vous pourrez alors passer à la rédaction de correctifs pour des tickets plus difficiles.
Si vous voulez commencer tout de suite (et personne ne vous le reprochera), jetez un coup d’œil à la liste des tickets simples qui ont besoin d’un correctif et des tickets simples qui ont des correctifs nécessitant une amélioration. Si vous êtes à l’aise dans l’écriture de tests, vous pouvez aussi examiner la liste des tickets simples qui ont besoin de tests. N’oubliez pas de suivre les instructions sur l’attribution de tickets qui étaient mentionnées dans le lien sur la documentation de Django sur l’appropriation de tickets et la soumission de correctifs.
Et ensuite ?¶
Quand un ticket possède un correctif, il doit être relu par une deuxième paire d’yeux. Après l’envoi d’un correctif ou la soumission d’une « pull request », prenez soin de mettre à jour les métadonnées du ticket en définissant les drapeaux du ticket « has patch », « doesn’t need tests », etc, pour que d’autres puissent les retrouver en vue d’une relecture. Contribuer ne signifie pas nécessairement écrire un correctif à partir de zéro. La relecture de correctifs existants est également une contribution très utile. Consultez Triaging tickets pour plus de détails.
