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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
|
<?xml version="1.0" encoding="ISO8859-1" standalone="no"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.2-Based Extension//EN"
"../../../share/sgml/freebsd42.dtd" [
<!ENTITY % entities PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Entity Set//FR" "../../share/sgml/entities.ent">
%entities;
]>
<!--
The FreeBSD Documentation Project
The FreeBSD French Documentation Project
$FreeBSD$
Original revision: n.nn
-->
<article lang="fr">
<articleinfo>
<title>Le Guide du Nouveau
“<foreignphrase>Committer</foreignphrase>”</title>
<authorgroup>
<author>
<surname>Projet de Documentation de FreeBSD</surname>
</author>
</authorgroup>
<pubdate>Septembre 1999</pubdate>
<copyright>
<year>1999</year>
<holder>Projet de Documentation de FreeBSD</holder>
</copyright>
<releaseinfo>$FreeBSD$</releaseinfo>
<abstract>
<para>Nouveau “<foreignphrase>committer</foreignphrase>”,
bienvenue dans l'équipe de développement de FreeBSD !</para>
<para>L'objectif de cette documentation est de vous orienter sur la
façon d'utiliser CVS sur la machine d'archive centrale de FreeBSD. Il
est présumé que vous avez déjà une connaissance de base de CVS,
quoique des informations de référence, des guides et Questions
Fréquemment Posées soient disponibles à l'adresse :
<ulink url="http://www.cyclic.com/cyclic-pages/books.html">http://www.cyclic.com/cyclic-pages/books.html</ulink></para>
<para>Bonne chance, et bienvenue à bord !</para>
&trans.a.haby;
</abstract>
</articleinfo>
<sect1 id="admin">
<title>Détails d'organisation</title>
<informaltable frame="none" orient="port">
<tgroup cols="2">
<tbody>
<row>
<entry><emphasis>Machine d'archive principale</emphasis></entry>
<entry><hostid>freefall.FreeBSD.org</hostid></entry>
</row>
<row>
<entry>
<emphasis>Machine d'archive internationale pour les codes de
cryptographie</emphasis>
</entry>
<entry><hostid>internat.FreeBSD.org</hostid></entry>
</row>
<row>
<entry><emphasis>Méthode de connexion</emphasis></entry>
<entry>&man.ssh.1;</entry>
</row>
<row>
<entry><emphasis>Répertoire CVSROOT</emphasis></entry>
<entry>/home/ncvs</entry>
</row>
<row>
<entry><emphasis>Répertoire CVSROOT pour la version internationale
des codes de cryptographie</emphasis></entry>
<entry>/home/cvs.crypt</entry>
</row>
<row>
<entry><emphasis>Administrateurs des archives CVS
principales</emphasis></entry>
<entry>&a.jdp; et &a.peter; ainsi que &a.asami; pour
<filename>ports/</filename></entry>
</row>
<row>
<entry>
<emphasis>Administrateur des archives CVS pour la version
internationale des codes de cryptographie</emphasis>
</entry>
<entry>&a.markm;</entry>
</row>
<row>
<entry><emphasis>Liste de diffusion</emphasis></entry>
<entry><email>cvs-committers@FreeBSD.org</email></entry>
</row>
<row>
<entry><emphasis>Etiquettes CVS importantes</emphasis></entry>
<entry>RELENG_3 (3.x-STABLE), HEAD (-CURRENT)</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Il vous est demandé d'utiliser &man.ssh.1; ou &man.telnet.1;
et Kerberos 5 pour vous connecter aux machines d'archive. Ces méthodes
sont globalement plus sûres qu'un simple &man.telnet.1; ou
&man.rlogin.1; parce que la négociation de l'authentification est
cryptée. Par défaut &man.ssh.1; crypte toute la session. Les utilitaires
disponibles &man.ssh-agent.1; et &man.scp.1; sont aussi bien plus
pratiques. Si vous ne connaissez pas &man.ssh.1;, reportez-vous à la
<xref linkend="ssh.guide"/>.</para>
</sect1>
<sect1 id="cvs.operations">
<title>Opérations CVS</title>
<para>Les opérations CVS se font habituellement en se connectant à
<hostid>freefall</hostid>, vérifiant que votre variable d'environnement
<envar>CVSROOT</envar> est bien positionnée à
<filename>/home/ncvs</filename>, et en effectuant les opérations
d'extraction (<foreignphrase>check-out</foreignphrase>) et de mise à
jour (<foreignphrase>check-in</foreignphrase>) nécessaires. Si vous
avez quelque chose de entièrement nouveau à ajouter (un nouveau logiciel
porté, du source d'origine externe, etc.), il existe une procédure
appelée <quote>easy-import</quote> qui facilite cette opération. Elle
ajoute automagiquement une entrée pour le nouveau module, fait ce qu'il
faut via <command>cvs import</command>, etc. – exécutez-la sans
arguments et elle vous demandera tout ce qu'elle a besoin de
savoir.</para>
<para>Si vous avez la pratique de CVS à distance et vous considérez
relativement opérationnel sur CVS en général, vous pouvez aussi effectuer
les opérations CVS directement depuis votre machine avec une copie
local à jour des sources. N'oubliez cependant pas de positionner
<envar>CVS_RSH</envar> à <wordasword>ssh</wordasword> de façon à
utiliser un moyen de transmission sécurisé et fiable. D'une autre côté,
si vous ne savez pas ce que cela veut dire, tenez-vous en s'il vous
plaît à la méthode qui consiste à vous connecter à
<hostid>freefall</hostid> et mettre en place vos modifications avec
&man.patch.1;.</para>
<para>Si vous avez à utiliser les opérations <command>add</command> et
<command>delete</command> pour faire en fait une opération
<quote>mv</quote>, il faut une copie sur l'archive plutôt que votre
commande CVS <command>add</command> suivie d'un
<command>delete</command>. Dans ce cas, un <link
linkend="conventions">Administrateur CVS</link> copiera le(s) fichier(s)
là où il(s) doi(ven)t aller et vous avertira une fois qu'il l'aura fait.
Le but de la copie dans les archives est de conserver l'historique des
modifications, la journalisation. Le Projet FreeBSD accorde une grande
importance à l'historique du projet que CVS nous permet de
conserver.</para>
</sect1>
<sect1 id="conventions">
<title>Conventions et Traditions</title>
<para>Les Administrateurs CVS (Peter Wemm et John Polstra) sont les
<quote>propriétaires</quote> des archives CVS et sont responsables de
chaque et de <emphasis>toute</emphasis> modification directe de
celles-ci pour mise au propre ou rectification d'erreur CVS dûe à un
<foreignphrase>committer</foreignphrase>. Personne d'autre ne doit
intervenir directement sur les archives. Si vous faites un fausse
manipulation, une importation incorrecte ou vous trompez d'étiquette
par exemple, n'essayez <emphasis role="bold">pas</emphasis> de la
rectifier vous-même ! Envoyez immédiatement un courrier
électronique ou téléphonez à John ou Peter et expliquez leur le
problème. Satoshi Asami est aussi Administrateur CVS pour la partie
<filename>ports/</filename> de l'arborescence. Mark Murray est
l'administrateur des archives internationales pour les logiciels de
cryptographie, en Afrique du Sud.</para>
<para>Si vous êtes nouveau <foreignphrase>committer</foreignphrase>, la
première chose à faire est de vous ajouter vous-même à la liste des
développeurs (section 28.2) du Manuel de Référence. Extraire le manuel
de référence et ajouter une entrée à la liste est relativement facile,
mais c'est néanmoins un bon test initial de vos compétences CVS. Si
vous pouvez le faire, vous n'aurez probablement pas de problèmes par
la suite.</para>
<para>L'étape suivante consiste à vous présenter aux autres
<foreignphrase>committers</foreignphrase>, sans quoi ils n'auront aucune
idée de qui vous êtes et à quoi vous travaillez. Il n'est pas
nécessaire de rédiger une biographie exhaustive, un paragraphe ou deux
suffiront, pour dire qui vous êtes et à quoi vous comptez travailler sur
FreeBSD. Envoyez-les par courrier électronique à
<email>cvs-committers@FreeBSD.org</email> et vous serez prêt à commencer
à travailler !</para>
<para>N'oubliez pas aussi de vous connecter à
<hostid>hub.FreeBSD.org</hostid> et de vous y créez un fichier
<filename>/var/forward/<replaceable>utilisateur</replaceable></filename>
(où <replaceable>utilisateur</replaceable> est votre nom d'utilisateur),
qui contienne votre adresse de courrier électronique principale où vous
souhaitez que le courrier électronique adressé à
<replaceable>votre_nom_d_utilisateur</replaceable>@FreeBSD.org vous soit
redirigé. Les boîtes aux lettres vraiment volumineuses qui demeurent en
en permanence sur <hostid>hub</hostid> sont souvent
<quote>accidentellement</quote> tronquées sans avertissement, redirigez
donc votre courrier, ou lisez-le, et vous ne le perdrez pas.</para>
<para>Tous les nouveaux <foreignphrase>committers</foreignphrase> ont un
mentor qui leur est assigné les premiers mois. Votre mentor est plus ou
moins chargé de vous expliquer tout ce que vous ne comprenez pas bien et
est aussi responsable de ce que vous faites à vos débuts. Si vous faites
une soumission erronée, c'est votre mentor qui sera ennuyé et vous
devriez probablement vous fixer comme ligne de conduite de faire passer
vos premières soumissions par lui avant de les intégrer aux
archives.</para>
<para>Toutes les soumissions doivent être intégrées d'abord à
<literal>-CURRENT</literal>, avant d'aller dans
<literal>-STABLE</literal>. Aucune nouvelle fonctionnalité ou
modification à haut risque ne devrait être intégrée à la branche
<literal>-STABLE</literal>.</para>
</sect1>
<sect1 id="developer.relations">
<title>Relations entre développeurs</title>
<para>Si vous travaillez directement sur votre propre code ou sur du code
dont il est bien établi que vous avez la responsabilité, il n'est
probablement pas nécessaire de valider ce que vous allez faire avec
d'autres développeurs avant de soumettre du code. Si vous trouvez un
bogue dans un module qui est manifestement orphelin (il y en a
malheureusement quelques uns), cela s'y applique aussi. Si, au
contraire, vous vous apprêtez à modifier quelque chose qui est
activement maintenu par quelqu'un d'autre (ce n'est qu'en surveillant
la &a.cvsall; que vous pourrez vous faire une idée de ce qu'il l'est et
de ce qui ne l'est pas), envisagez alors de lui envoyer vos
modifications, tout comme vous l'auriez fait quand vous n'étiez pas
<foreignphrase>committer</foreignphrase>. Pour les logiciels portés,
vous devriez contacter la personne listée comme
<makevar>MAINTAINER</makevar> dans le <filename>Makefile</filename>.
Pour le reste des archives, si vous n'êtes pas sûr de qui maintient
effectivement tel ou tel module, il peut être utile de passer en revue
le résultat de <command>cvs log</command> pour voir qui a soumis des
modifications dans le passé. Si vous ne trouvez personne, ou si la
personne en charge montre un désintérêt pour la partie en question,
allez-y et faites vos modifications.</para>
<para>Si vous avez pour une raison ou une autre des doutes à propos d'une
soumission que vous envisagez, faites-la d'abord examiner par
<literal>-hackers</literal> avant de l'intégrer. Il vaut mieux que l'on
vous fasse des remarques alors, qu'une fois qu'elle fera partie des
archives CVS. S'il vous arrive de soumettre quelque chose qui soulève
une controverse, envisagez éventuellement de faire marche arrière
en attendant que la question soit réglée. N'oubliez pas – avec
CVS, vous pourrez toujours remettre votre modification en
service.</para>
</sect1>
<sect1 id="gnats">
<title>GNATS</title>
<para>Le Projet FreeBSD utilise <application>GNATS</application> pour
enregistrer les rapports de bogues et les demandes de modification. Si
vous effectuez une correction ou une modification décrite dans un
PR - <foreignphrase>Problem Report</foreignphrase>, rapport
d'anomalie - <application>GNATS</application>, veillez à
utiliser
<command>edit-pr <replaceable>numéro_de_pr</replaceable></command>
sur <hostid>freefall</hostid> pour le fermer. L'usage veut aussi que
vous preniez le temps de fermer les rapports ayant trait à vos
soumission, le cas échéant. Vous pouvez aussi utiliser vous-même
&man.send-pr.1; pour proposer les modifications dont vous pensez qu'il
faut les probablement les faire, après une revue plus extensive par
les autres participants.</para>
<para>Vous trouverez plus d'informations sur
<application>GNATS</application> aux adresses suivantes :</para>
<itemizedlist>
<listitem>
<para><ulink url="http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html">http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.FreeBSD.org/support.html">http://www.FreeBSD.org/support.html</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.FreeBSD.org/send-pr.html">http://www.FreeBSD.org/send-pr.html</ulink></para>
</listitem>
<listitem>
<para>&man.send-pr.1;</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="people">
<title>Who's Who</title>
<para>En dehors de Peter Wemm et John Polstra, les administrateurs des
archives, il y a d'autres membres du Projet FreeBSD que vous
rencontrerez probablement dans votre nouvelle fonction de
<foreignphrase>committer</foreignphrase>. Rapidement, et en aucun
cas exhaustivement, ce sont :</para>
<variablelist>
<varlistentry>
<term>&a.asami;</term>
<listitem>
<para>Est le responsable du catalogue des logiciels portés, ce qui
signifie qu'il a le pouvoir de décision en ce qui concerne toute
modification aux logiciels portés et à leurs macros-instructions
de compilation. Il est aussi responsable la gestion des gels du
code entre deux versions.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.bde;</term>
<listitem>
<para>Est l'<foreignphrase>Obersturmbahnfuhrer</foreignphrase> de la
Police du Style. Quand vous soumettez quelque chose que vous
auriez pu faire mieux, Bruce sera là pour vous le signaler.
Remerciez-le qu'il y ait quelqu'un pour le faire.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.dg;</term>
<listitem>
<para>Est notre architecte principal et superviseur du système de
gestion de la mémoire virtuelle. Si vous envisagez une
modification de ce système, voyez cela avec David. Si vous êtes
pris dans une discussion âpre et insoluble avec un autre
participant à propos d'une modification envisagée (ce qui,
heureusement, ne se produit pas souvent), il peut aussi
occasionnellement être nécessaire de demander alors à David
de mettre sa casquette d'Architecte Principal et de prendre la
décision finale.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.jkh;</term>
<listitem>
<para>Est le responsable des versions. Il a la charge de définir les
dates butées et de superviser le processus de mise en place de la
nouvelle version. Pendant les gels du code, il a aussi le pouvoir
de décision sur toutes les modifications sur la branche de code
qui est en cours de finalisation. S'il y a quelque chose que vous
voudriez voir reporter de <literal>-CURRENT</literal> dans
<literal>-STABLE</literal> (quelqu'intérêt que cela puisse avoir à
un moment donné), c'est aussi la personne à qui il faut en
parler.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.markm;</term>
<listitem>
<para>Mark est le responsable des archives CVS internationales pour
le code de cryptographie, sur
<hostid>internat.FreeBSD.org</hostid> en Afrique du Sud.</para>
<para>Mark supervise la plupart du code de cryptographie ; si
vous vous y envisagez des mises à jour, parlez-en s'il vous plaît
d'abord à Mark.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.steve;</term>
<listitem>
<para>Steve est le responsable non officiel de
<filename>/usr/src/bin</filename>. S'il y a quelque chose
d'important que vous voudriez y voir, vous devriez probablement
envisager d'abord cela avec Steve. Il est aussi administrateur des
“<foreignphrase>Problem Report</foreignphrase>”, en
coopération avec &a.phk;.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.brian;</term>
<listitem>
<para>Maintient officiellement
<filename>/usr/bin/ppp</filename> et
<application>LPD</application>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.wollman;</term>
<listitem>
<para>Si vous avez besoin d'un conseil sur des points obscurs du
code réseau ou n'êtes pas certain d'une modification que vous
envisagez à ce sous-système, c'est avec Garrett qu'il faut en
discuter.</para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1 id="ssh.guide">
<title>Introduction rapide à <application>SSH</application></title>
<procedure>
<step>
<para>Mettez à jour et installez le logiciel porté
<application>ssh</application> dans
<filename>/usr/ports/security/ssh</filename> (il faut une version
1.2.25 ou postérieure).</para>
</step>
<step>
<para>Veillez à exécuter &man.ssh-agent.1; avant toute autre
application. Les utilisateurs de <application>X</application>, par
exemple, le font habituellement depuis leur fichier
<filename>.xsession</filename> ou
<filename>.xinitrc</filename>. Reportez-vous à &man.ssh-agent.1;
pour plus de détails.</para>
</step>
<step>
<para>Générez une paire de clés avec &man.ssh-keygen.1;. Ces clés
seront créées dans le répertoire
<filename><envar>$HOME</envar>/.ssh</filename>.</para>
</step>
<step>
<para>Copiez votre clé publique
(<filename><envar>$HOME</envar>/.ssh/identity.pub</filename>)
dans le fichier <filename>authorized_keys</filename> de votre
répertoire utilisateur sur <hostid>freefall</hostid>
(i.e.
<filename><envar>$HOME</envar>/.ssh/authorized_keys</filename>).
</para>
</step>
</procedure>
<para>Vous devriez maintenant pouvoir utiliser &man.ssh-add.1; pour vous
authentifier à chaque début de session. Il vous demandera la phrase clé
pour votre clé privée, et l'enregistrera via votre agent
d'authentification (&man.ssh-agent.1;) de façon à ce que vous n'ayez
plus à la retaper à chaque fois.</para>
<para>Testez en faisant quelque chose du style : <command>ssh
freefall.FreeBSD.org ls /usr</command>.</para>
<para>Pour plus d'informations, reportez-vous à
<filename>/usr/ports/security/ssh</filename>, &man.ssh.1;,
&man.ssh-agent.1;, &man.scp.1;, et &man.ssh-keygen.1;.</para>
</sect1>
<sect1>
<title>Régles à Suivre par les <foreignphrase>Committers</foreignphrase>
FreeBSD</title>
<orderedlist>
<listitem>
<para>Respectez les autres
<foreignphrase>committers</foreignphrase>.</para>
</listitem>
<listitem>
<para>Discutez de toute modification importante
<emphasis>avant</emphasis> intégration.</para>
</listitem>
<listitem>
<para>Respectez les responsables de la maintenance s'il y en a de
définis par la variable <makevar>MAINTAINER</makevar> du
<filename>Makefile</filename> ou dans le fichier
<filename>MAINTAINER</filename> au premier niveau de
l'arborescence.</para>
</listitem>
<listitem>
<para>N'intervenez jamais directement sur les archives. Demandez au
reponsable de ces archives de le faire.</para>
</listitem>
<listitem>
<para>Toute modification controversée doit, si le responsable de
la maintenance ou l'Architecte Principal le demande, être annulée
jusqu'à ce que la discussion soit terminée. Les modifications pour
des questions de sécurité peuvent être effectuées par l'Officier de
Sécurité, malgré les souhaits d'un responsable de la
maintenance.</para>
</listitem>
<listitem>
<para>Les modifications doivent être faites dans
<literal>-current</literal> avant d'être reportées dans
<literal>-stable</literal> sauf autorisation expresse du
responsable des versions ou si elles ne s'appliquent pas à
<literal>-current</literal>. Toute modification non triviale ni
urgente doit rester au moins trois jours dans
<literal>-current</literal> pour être testée suffisamment avant
d'être reportée. Le responsable des versions a les mêmes
prérogatives sur la branche <literal>-stable</literal> que celles
décrites, pour ce qui concerne l'Architecte Principal, par le règle
#5.</para>
</listitem>
<listitem>
<para>Ne vous disputez pas publiquement avec les autres
<foreignphrase>committers</foreignphrase> ; cela fait mauvais
effet. Si vous êtes en “profond” désaccord sur un point,
n'en discutez qu'en privé.</para>
</listitem>
<listitem>
<para>Respectez tous les gels du code et lisez régulièrement la liste
de diffusion pour les <foreignphrase>committers</foreignphrase> pour
savoir quand il y en a.</para>
</listitem>
<listitem>
<para>En cas de doute sur une procédure, renseignez-vous
d'abord !</para>
</listitem>
<listitem>
<para>Testez vos modifications avant de les intégrer.</para>
</listitem>
</orderedlist>
<para>Comme indiqué, enfreindre l'un de ces règles peut entraîner une
suspension provisoire, et, en cas de récidive, une suppression
permanente des privilèges de <foreignphrase>committers</foreignphrase>.
Trois membres ou plus de l'équipe de base, ou l'Architecte Principal et
un autre membre de l'équipe de base, peuvent, s'ils en sont d'accord,
suspendre temporairement ces privilèges jusqu'à ce que l'ensemble de
<literal>-core</literal> examine la question. En cas
d'<quote>urgence</quote> (un <foreignphrase>committer</foreignphrase>
endommageant les archives), une suspension provisoire peut aussi être
décidée par l'un des administrateurs des archives ou tout autre membre
de l'équipe de base qui se trouve être réveillé à ce moment-là. Seule la
totalité de l'équipe de base peut suspendre pour une durée importante
les droits d'un <foreignphrase>committer</foreignphrase>, ou les
retirer définitivement, cette dernière mesure n'étant en général prise
qu'après consultation avec les
<foreignphrase>committers</foreignphrase>. Le but de cette règle n'est
pas de faire de l'équipe de base une bande de dictateurs cruels qui
puissent disposer des <foreignphrase>committers</foreignphrase> comme de
cannettes vides, mais d'avoir une sorte de fusible pour le projet. Si
quelqu'un est sévèrement incontrôlable, il est important de pouvoir
réagir immédiatement, au lieu d'être paralysé par la discussion. Dans
tous les cas, le <foreignphrase>committers</foreignphrase> dont les
privilèges sont suspendus a le droit d'être “entendu”, c'est
à ce moment-là qu'il est décidé de la durée totale de la suspension. Il
peut aussi demander un révision de la décision après 30 jours et tous
les 30 jours ensuite (à moins que la durée totale de la suspension soit
inférieure à 30 jours). Quelqu'un à qui les privilèges ont été
définitivement retiré peut demander que son cas soit revu après 6 mois.
La procédure de révision est <emphasis>strictement
informelle</emphasis>, et, dans tous les cas, l'équipe de base se
réserve le droit de prendre en compte ou d'ignorer les demandes de
révision, si elle pense que sa décision initiale était la bonne.</para>
<para>Pour toutes les autres aspects du fonctionnement du projet, l'équipe
de base est un sous-ensemble des
<foreignphrase>committers</foreignphrase> et est soumise aux
<emphasis>même</emphasis> règles. Ce n'est pas parce que quelqu'un
appartient à l'équipe de base qu'il est dispensé de suivre les
instructions que l'on vient de donner, les “pouvoirs
spéciaux” de l'équipe de base ne sont effectifs que lorsqu'elle
agit en tant que groupe, pas individuellement.
Individuellement, nous sommes tous d'abord des
<foreignphrase>committers</foreignphrase> et ensuite seulement membres
de l'équipe de base.</para>
<sect2>
<title>Détails</title>
<orderedlist>
<listitem>
<para>Respectez les autres
<foreignphrase>committers</foreignphrase>.</para>
<para>Cela signifie que vous devez traiter les autres
<foreignphrase>committers</foreignphrase> en tant que groupe de
co-développeurs qu'ils sont en fait. Malgré nos tentatives
occasionnelles pour prouver le contraire, on ne devient pas
<foreignphrase>committer</foreignphrase> en étant stupide et
rien n'est plus irritant que d'être traité comme tel par un de vos
collaborateurs. Que nous apprécions toujours quelqu'un d'autre
ou pas (chacun a ses jours sans), nous devons malgré tout toujours
<emphasis>traiter</emphasis> les autres avec respect, sans quoi
c'est toute l'organisation de l'équipe qui se désagrège
rapidement.</para>
<para>Etre capable de travailler ensemble à long terme est le plus
grand atout du projet, bien plus important que n'importe quel
série de modifications du code, et transformer les discussions à
propos du code en disputes qui affectent notre capacité à
travailler harmonieusement ensemble à long terme n'en vaut
vraiment pas la peine, quelque justification que l'on puisse
imaginer.</para>
<para>Pour respecter cette règle, n'envoyez pas de courrier
électronique quand vous êtes en colère et ne vous comportez en
outre pas de façon à paraître inutilement agressif aux autres.
Commencez par vous calmer et réfléchissez à la manière la plus
efficace de convaincre l(es) autre(s) personne(s) de la justesse
de votre point de vue. Ne partez pas sur les chapeaux de roues
pour vous sentir simplement immédiatement mieux au prix d'une
dispute à long terme. Non seulement c'est une mauvaise
“gestion des ressources”, mais les responsables du
projet sanctionneront sévèrement les manifestations d'agressivité
publiques et répétées, jusqu'à suspendre ou vous retirer
définitivement vos privilèges de
<foreignphrase>committer</foreignphrase>. Ce n'est pas une chose
qu'ils aiment le moins du monde faire, mais l'unité est la
priorité. Aucune dose de code ou de judicieux conseils ne s'y
mesure.</para>
</listitem>
<listitem>
<para>Discutez de toute modification importante
<emphasis>avant</emphasis> intégration.</para>
<para>Ce n'est pas dans les archives CVS que les modifications
doivent être intégrées pour validation ou discussion, cela doit
se faire d'abord sur les listes de discussion et être intégré
ensuite lorsqu'on est arrivé à quelque chose qui approche du
consensus. Cela ne signifie pas que vous deviez demander la
permission avant de corriger chaque erreur évidente de syntaxe ou
d'orthographe dans une page de manuel, mais simplement que vous
devriez essayer de sentir quand vous envisagez une modification
qui n'est pas aussi triviale et qui demande à être discutée au
préalable. Les gens n'ont rien contre les modifications
d'envergure si le résultat en est quelque chose de nettement
meilleur que ce qu'ils avaient auparavant, mais ils n'aiment pas
être <emphasis>surpris</emphasis> par ces modifications. La
meilleure façon de vous assurer que vous allez dans le bon sens et
de faire valider votre code par un ou plusieurs autres
<foreignphrase>committers</foreignphrase>.</para>
<para>En cas de doute, demandez une validation !</para>
</listitem>
<listitem>
<para>Respectez les responsables de la maintenance, s'il y en
a.</para>
<para>De nombreuses parties de FreeBSD n'“appartiennent”
à personne, c'est-à-dire qu'il n'y aura personne pour pousser de
hauts cris si vous faites des modifications sur “leur”
terrain, mais il vaut mieux s'en assurer d'abord. Une de nos
convention est de mettre une ligne indiquant qui maintient dans le
<filename>Makefile</filename> du paquetage ou de la
sous-arborescence activement maintenue par une ou plusieurs
personnes voyez <ulink
url="http://www.FreeBSD.org/handbook/policies.html">http://www.FreeBSD.org/handbook/policies.html</ulink>
pour plus d'information à ce sujet. Quand il y a plusieurs
personnes qui maintiennent une même section de code, les
soumissions d'une de ces personnes sur ces sections doivent être
revues par au moins une des autres personnes qui la maintiennent.
Dans le cas où l'<quote>attribution</quote> n'est pas claire,
vous pouvez aussi consulter les messages de CVS pour les
fichiers concernés, pour voir si quelqu'un a travaillé dessus
récemment ou travaille de façon prédominante sur ce
domaine.</para>
<para>Il y a d'autres parties de FreeBSD qui sont contrôlées par
quelqu'un qui gère tout un domaine de l'évolution de FreeBSD,
l'internationalisation ou le réseau par exemple. Reportez-vous à
<ulink
url="http://www.FreeBSD-fr.org/handbook/staff-who.html">http://www.FreeBSD.org/handbook/staff-who.html</ulink>
pour avoir plus d'informations à ce sujet.</para>
</listitem>
<listitem>
<para>N'intervenez jamais directement sur les archives. Demandez à
un responsable des archives de le faire.</para>
<para>C'est assez clair - vous n'avez pas le droit de
faire de modifications directement sur les archives, point. En cas
de difficultés, adressez-vous à l'un des responsables des
archives en envoyant un courrier électronique à
<email>cvs@FreeBSD.org</email> et attendez qu'ils corrigent le
problème et vous relancent. N'essayez pas de régler le problème
vous-même !</para>
<para>Si vous envisagez de supprimer un étiquette ou d'en mettre une
nouvelle, ou bien d'importer du code sur nouvelle branche, il vous
sera peut-être utile de demander d'abord un avis. Nombreux sont
ceux qui se trompent en faisant cela les premières fois et cela
aboutit à la modification de nombreux fichiers et irrite les
utilisateurs de <application>CVSup/CTM</application> qui recoivent
tout à coup de nombreuses mises à jour inutiles.</para>
</listitem>
<listitem>
<para>Toute modification controversée doit, si le responsable de
la maintenance ou l'Architecte Principal le demande, être annulée
jusqu'à ce que la discussion soit terminée. Les modifications pour
des questions de sécurité peuvent être effectuées par l'Officier
de Sécurité, malgré les souhaits d'un responsable de la
maintenance.</para>
<para>Ce peut être dur à avaler en cas de conflit (quand chaque
partie est bien sûr convaincue qu'elle a raison) mais CVS permet
d'éviter de prolonger la dispute, il est bien plus facile de
revenir sur les modifications, d'attendre que tout le monde se
calme et d'essayer de voir quelle est la meilleure solution.
S'il s'avère que la modification était la bonne chose à faire,
elle peut-être facilement remise en service. Dans le cas contraire,
les utilisateurs n'auront pas eu à subir l'évolution erronée le
temps que tout le monde ait débattu de sa pertinence. Il est très
rare que l'on ait à revenir sur des modifications archivées, parce
que la discussion met la plupart du temps en évidence les
interventions controversés ou non justifiées avant même qu'elles
n'aient été intégrées, mais dans les rares cas où cela se produit,
il faut revenir en arrière sans discuter de façon à ce que l'on
puisse immédiatement examiner s'il y avait erreur ou non.</para>
</listitem>
<listitem>
<para>Les modifications doivent être faites dans
<literal>-current</literal> avant d'être reportées dans
<literal>-stable</literal> sauf autorisation expresse du
responsable des versions ou si elles ne s'appliquent pas à
<literal>-current</literal>. Toute modification non triviale ni
urgente doit rester au moins trois jours dans
<literal>-current</literal> pour être testée suffisamment avant
d'être reportée. Le responsable des versions a les mêmes
prérogatives sur la branche <literal>-stable</literal> que celles
décrites, pour ce qui concerne l'Architecte Principal, par le règle
#5</para>
<para>C'est un autre point <quote>sans appel</quote> parce que c'est
l'ingénieur de version qui est en dernier lieu responsable (et
encaisse les coups) si une modification s'avère mal fondée.
Respectez s'il vous plaît cette règle et coopérez totalement
avec le responsable des versions pour ce qui concerne la branche
<literal>-stable</literal>. La gestion de la branche
<literal>-stable</literal> peut parfois paraître excessivement
conservatrice à un observateur occasionnel, mais rappelez vous que
c'est le principe même de <literal>-stable</literal> et que
<literal>-current</literal> suit d'autres règles. Il n'y a aucune
raison d'avoir une branche <literal>-current</literal> si toutes
les modifications vont immédiatement dans
<literal>-stable</literal>, sans pouvoir d'abord être testées par
les développeurs de <literal>-current</literal>, laissez donc
passer un peu de temps avant de les reporter dans
<literal>-stable</literal>, à moins que la modification ne soit
critique, urgente, ou suffisamment triviale pour rendre tout
test ultérieur superflu (correction d'orthographe dans les pages
de manuel, de bogue flagrant ou de faute de frappe, etc.) En
d'autres termes, faites preuve de bon sens.</para>
</listitem>
<listitem>
<para>Ne vous disputez pas publiquement avec les autres
<foreignphrase>committers</foreignphrase> ; cela fait mauvais
effet. Si vous êtes en “profond” désaccord sur un point,
n'en discutez qu'en privé.</para>
<para>Le projet a une image publique à conserver et cette image est
très importante pour nous tous, en particulier si nous voulons
continuer à attirer de nouveaux membres. Il y aura des situations
où, malgré tous les efforts de chacun pour rester mesurés,
certains perdront leur calme et laisserons leur colère s'exprimer,
et le mieux que nous puissions faire est d'essayer d'en minimiser
les effets jusqu'à ce que chacun se soit de nouveau calmé. Cela
signifie que vous ne devez ni laisser exprimer votre colère en
public, ni faire suivre de courriers privés sur des listes ou des
alias publics. Ce que les gens se disent entre eux est souvent
moins édulcoré que ce qu'ils disent en public, et ce type
d'échange n'y a donc pas sa place - cela ne peut
qu'envenimer une situation déjà regrettable. Si la personne qui
vous adresse des reproches prend au moins la précaution de le
faire en privé, ayez vous aussi la correction de le garder pour
vous. Si vous estimez avoir été injustement traité par un autre
développeur et que cela vous soucie, parlez-en à l'équipe de base
plutôt qu'en public. Nous ferons de notre mieux pour jouer les
médiateurs et ramener les choses au raisonnable. Quand la
discussion a trait à une modifications de code et que les
participants n'arrivent apparemment pas à se mettre d'accord,
l'équipe de base peut désigner une troisième partie ayant l'accord
mutuel pour résoudre le problème. Les autres personnes impliquées
doivent alors accepter de se plier aux décisions de cette
troisième partie.</para>
</listitem>
<listitem>
<para>Respectez tous les gels du code et lisez régulièrement la
liste de diffusion pour les
<foreignphrase>committers</foreignphrase> pour savoir quand il y
en a.</para>
<para>Soumettre des modifications pendant un gel du code est
vraiment une grave erreur et l'on attend des
<foreignphrase>committers</foreignphrase> qu'ils se tiennent au
courant de ce qui se passe avant de se remanifester après une
longue absence et soumettre 10 Mo de code accumulés pendant ce
temps. Les gens qui se comportent régulièrement de cette façon
verront leurs privilèges de
<foreignphrase>committers</foreignphrase> suspendus jusqu'à leur
retour du Joyeux Camp de Rééducation de FreeBSD que nous gérons
au Gröenland.</para>
</listitem>
<listitem>
<para>En cas de doute sur une procédure, renseignez-vous
d'abord !</para>
<para>De nombreuses erreurs sont commises parce que quelqu'un est
pressé et estime qu'il sait quelle est la meilleure façon de
faire quelque chose. Il y a des bonnes chances que vous ne sachiez
en fait pas comment faire ce que vous n'avez encore jamais fait et
que vous ayez vraiment besoin de demander d'abord sans quoi vous
allez vous mettre publiquement dans l'embarras. Il n'y a aucune
honte à demander “Comment diable fait-on cela ?”,
nous savons déjà que vous êtes quelqu'un d'intelligent, sans quoi
vous ne seriez pas
<foreignphrase>committer</foreignphrase>.</para>
</listitem>
<listitem>
<para>Testez vos modifications avant de les intégrer.</para>
<para>Cela peut paraître évident, mais si c'était vraiment le cas,
nous ne verrions probablement pas autant de cas où les gens ne le
font manifestement pas. Si vos modifications touchent le noyau,
vérifiez que vous pouvez toujours compiler et
<literal>GENERIC</literal> et <literal>LINT</literal>. Si vos
modifications s'appliquent ailleurs, assurez-vous que vous pouvez
toujours compiler l'ensemble du système - <command>make
world</command>. Si vous faites vos modifications sur une branche
donnée, veillez à tester vos modifications sur une machine qui
utilise cette version du système. Si votre modifications risque
de poser des problèmes sur une autre architecture matérielle,
veillez à tester sur toutes les architectures supportées. Nous
n'avons actuellement qu'x86 et Alpha, c'est donc assez facile à
faire. Si vous avez besoin de tester sur l'AXP, votre compte sur
<hostid role="fqdn">beast.FreeBSD.org</hostid> vous permet de
compiler et tester des binaires/noyaux/etc. sur Alpha. Quand
d'autres architectures seront ajoutées à la liste des
plates-formes supportées par FreeBSD, des ressources partagées
de test seront disponibles.</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Autres suggestions</title>
<para>Quand vous intégrez des modifications de la documentation,
utilisez un correcteur orthographique avant de soumettre. Pour toutes
les documentations en SGML, vous devriez aussi vérifier que vos
directives de formatage sont valides, avec un <command>make
lint</command>.</para>
<para>Pour toutes les pages de manuel en ligne, servez-vous de
<command>manck</command> (au catalogue des logiciels portés) sur la
page pour vérifier que toutes les références croisées et noms de
fichiers sont corrects et que les <makevar>MKLINK</makevar>s
appropriés sont installés.</para>
</sect2>
</sect1>
<sect1>
<title>Questions Fréquemment Posées propres aux logiciels portés</title>
<qandaset>
<qandadiv>
<title>Importer un nouveau logiciel</title>
<qandaentry>
<question>
<para>Comment faire pour importer un nouveau logiciel ?</para>
</question>
<answer>
<para>Lisez s'il vous plaît d'abord la section sur la copie des
archives.</para>
<para>Pour importer un nouveau logiciel, le plus facile est
d'utiliser la procédure <command>easy-import</command> sur
<hostid>freefall</hostid>. Elle vous posera quelques questions
et importera directement le logiciel dans le répertoire que vous
aurez indiqué. Elle a été écrite par &a.joerg;, envoyez-lui
s'il vous plaît un courrier électronique si vous avez des
questions à propos de <command>easy-import</command>.</para>
<para>Il y a une chose qu'elle ne fera pas à votre place :
ajouter le logiciel au <filename>Makefile</filename> du
répertoire de niveau supérieur (catégorie). Il faudra le faire
vous-même.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Y'a-t-il d'autres choses qu'il faut que je sache quand
j'importe un nouveau logiciel ?</para>
</question>
<answer>
<para>Vérifiez votre portage, pour vous assurez qu'il compile et
que le paquetage est correctement construit. Voici ce qu'il est
recommandé de faire :</para>
<screen>&prompt.user; <userinput>make install</userinput>
&prompt.user; <userinput>make package</userinput>
&prompt.user; <userinput>make deinstall</userinput>
&prompt.user; <userinput>pkg_add <replaceable>le_paquetage_que_vous_venez_de_compiler</replaceable></userinput>
&prompt.user; <userinput>make deinstall</userinput>
&prompt.user; <userinput>make reinstall</userinput>
&prompt.user; <userinput>make package</userinput>
</screen>
<para>Le chapitre
<ulink url="../handbook/porting.html">faire vous-même un
portage</ulink> du Manuel de Référence vous donnera des
instructions plus détaillées.</para>
<para>Utilisez &man.portlint.1; pour vérifier la syntaxe du
portage. Il n'est pas indispensable d'éliminer la totalité des
messages d'avertissement, mais veillez à régler les problèmes
les plus évidents.</para>
<para>Si le logiciel porté a été soumis par quelqu'un qui n'a
jamais collaboré au projet auparavant, ajoutez le nom de cette
personne à la section <citetitle pubwork="section">Autres
Collaborateurs</citetitle> du Manuel de Référence.</para>
<para>Fermez le PR, si le portage résulte d'un PR. Pour fermer un
PR, il suffit d'exécuter <userinput>edit-pr
<replaceable>PR#</replaceable></userinput> sur
<hostid>freefall</hostid> et de modifier la valeur de la
variable <varname>state</varname> de <constant>open</constant>
en <constant>closed</constant>. On vous demandera d'entrer un
commentaire, et c'est tout.</para>
</answer>
</qandaentry>
</qandadiv>
<qandadiv>
<title>Copies des archives</title>
<qandaentry>
<question>
<para>Quand avons-nous besoin qu'une opération de copie soit faite
sur les archives ?</para>
</question>
<answer>
<para>Quand vous voulez importer un logiciel en rapport avec un
autre logiciel déjà archivé dans un autre répertoire, envoyez
s'il vous plaît un courrier électronique au responsable des
logiciels portés pour lui demander son avis.
<wordasword>En rapport</wordasword> désigne ici une version
différente ou une version légèrement modifiée. En exemple, on
peut citer <filename>print/ghostscript*</filename> (versions
différentes) et <filename>x11-wm/windowmaker*</filename>
(version Anglaise et version internationalisée).</para>
<para>Comme autre exemple, on peut citer le cas d'un logiciel porté
déplacé d'un sous-répertoire à un autre, ou d'une modification du
nom d'un répertoire parce que l'auteur a changé le nom de son
logiciel, bien qu'il dérive d'un logiciel déjà importé.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Quand n'avons-nous <emphasis>pas</emphasis> besoin q'une
opération de copie soit faite sur les archives ?</para>
</question>
<answer>
<para>Quand il n'y a pas d'historique à conserver. Si un logiciel
est importé dans une catégorie erronée et immédiatement
déplacé, il suffit d'un simple <command>cvs remove</command> de
l'ancien suivi d'un <command>cvs import</command> du
nouveau.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Que faut-il que je fasse ?</para>
</question>
<answer>
<para>Envoyez un courrier électronique au responsable des
logiciels portés, qui fera la copie de l'ancien emplacement vers
le nouveau. Vous en serez averti, et l'on attendra alors de vous
que vous exécutiez les opérations suivantes :</para>
<procedure>
<step>
<para><command>cvs remove</command> de l'ancien logiciel (si
besoin est),</para>
</step>
<step>
<para>Correction du <filename>Makefile</filename> de niveau
supérieur (catégorie),</para>
</step>
<step>
<para>Mise à jour de
<filename>CVSROOT/modules</filename></para>
</step>
<step>
<para>Si d'autres logiciels dépendent de celui qui vient
d'être mis à jour, correction des lignes décrivant leurs
dépendances dans leurs
<filename>Makefile</filename>s,</para>
</step>
<step>
<para>Si le logiciel a changé de catégories, modification en
conséquence de la ligne <makevar>CATEGORIES</makevar> du
<filename>Makefile</filename> du logiciel.</para>
</step>
</procedure>
</answer>
</qandaentry>
</qandadiv>
<qandadiv>
<title>Gel des logiciels portés</title>
<qandaentry>
<question>
<para>Qu'est-ce qu'un <quote>gel des logiciels
portés</quote> ?</para>
</question>
<answer>
<para>Avant livraison d'une nouvelle version, il est nécessaire de
limiter les interventions sur les archives des logiciels portés
pendant une courte période, le temps que les paquetages et la
version elle-même soient compilés. Cela pour garantir la
cohérence entre les différents composants de la version, c'est
cela que l'on appelle le <quote>gel des logiciels
portés</quote>.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Combien de temps dure ce gel ?</para>
</question>
<answer>
<para>Habituellement deux à trois jours.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Qu'est-ce que cela signifie pour moi ?</para>
</question>
<answer>
<para>Pendant le gel des logiciels portés, vous ne devez pas
soumettre quoi que ce soit dans l'arborescence des logiciels
portés, sauf autorisation explicite du responsable des
logiciels. <quote>Autorisation explicite</quote> correspond ici
à l'un des deux cas de figure suivants :</para>
<itemizedlist>
<listitem>
<para>Vous avez posé la question au responsable des logiciels,
et il vous a répondu : <quote>Allez-y,
intégrez</quote>.</para>
</listitem>
<listitem>
<para>Le responsable des ports vous a envoyé un courrier
électronique, soit directement, soit à la liste de
diffusion, pour signaler un problème à corriger sur le
logiciel.</para>
</listitem>
</itemizedlist>
<para>Notez bien que vous n'êtes pas implicitement autorisé à
corriger un logiciel pendant un gel simplement parce qu'il ne
compile plus.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Comment suis-je averti du début du gel des
logiciels ?</para>
</question>
<answer>
<para>Le responsable des logiciels portés enverra des messages
d'avertissement sur la &a.ports; et la &a.committers; pour
annoncer la mise en oeuvre prochaine d'une nouvelle version,
habituellement deux à trois semaines à l'avance. La date exacte
ne sera définitivement fixée que quelques jours avant. Cela
parce que le gel des logiciels doit être synchronisé avec la
mise en oeuvre de la version elle-même, et que ce n'est qu'à ce
moment-là que l'on sait exactement quand cette opération aura
lieu.</para>
<para>Quand le gel commencera, il y aura bien sûr une nouvelle
annonce sur la &a.committers;.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Comment suis-je averti de la fin du gel des
logiciels ?</para>
</question>
<answer>
<para>Quelques heures après la mise en place de la nouvelle
version, le responsable des logiciels enverra un courrier
électronique à la &a.ports; et à la &a.committers; pour annoncer
la fin du gel des logiciels. Remarquez que la finalisation de la
version n'implique pas automatiquement la fin du gel. Nous
devons nous assurer qu'un problème de dernière minute ne demande
pas de reconstruction immédiate de la version.</para>
</answer>
</qandaentry>
</qandadiv>
<qandadiv>
<title>Questions diverses</title>
<qandaentry>
<question>
<para>Comment sais-je si un logiciel porté compile correctement ou
non ?</para>
</question>
<answer>
<para>Commencez par consulter
<ulink url="http://bento.FreeBSD.org/~asami/errorlogs/">http://bento.FreeBSD.org/~asami/errorlogs/</ulink>.
Vous y trouverez les messages d'erreurs des dernières
compilations des logiciels portés sous
<literal>3-stable</literal> et
<literal>4-current</literal>.</para>
<para>Néanmoins, il ne suffit pas qu'un logiciel n'y apparaisse
pas pour pouvoir dire qu'il compile correctement. (Une de ses
dépendances, par exemple, peut ne pas avoir compilé.) Voici les
répertoires de <hostid>bento</hostid>, n'hésitez pas à aller y
voir :</para>
<programlisting>
/a/asami/portbuild/3/errors messages d'erreur de la dernière compilation de 3-stable
/logs tous les messages de la dernière compilation de 3-stable
/packages messages d'erreur sur les paquetages de la dernière compilation 3-stable
/bak/errors messages d'erreur de la dernière compilation intégrale de 3-stable
/bak/logs tous les messages de la dernière compilation de l'intégrale de 3-stable
/bak/packages messages d'erreur sur les paquetages de la dernière compilation intégrale de 3-stable
/4/errors messages d'erreur de la dernière compilation de 4-current
/logs tous les messages de la dernière compilation de 4-current
/packages messages d'erreur sur les paquetages de la dernière compilation 4-current
/bak/errors messages d'erreur de la dernière compilation intégrale de 4-current
/bak/logs tous les messages de la dernière compilation de l'intégrale de 4-current
/bak/packages messages d'erreur sur les paquetages de la dernière compilation intégrale de 4-current
</programlisting>
<para>Essentiellement, si le logiciel apparaît dans
<filename>packages</filename>, ou dans
<filename>logs</filename> mais pas dans
<filename>errors</filename>, il compile correctement. (Les
répertoires <filename>errors</filename> contiennent ce que vous
voyez sur la page Web.)</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>J'ai importé un nouveau logiciel. Dois-je l'ajouter au
fichier <filename>INDEX</filename> ?</para>
</question>
<answer>
<para>Non. Le responsable des logiciels portés regénère
l'<filename>INDEX</filename> et l'intègre régulièrement aux
archives.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Y'a-t-il d'autres fichiers auxquels je ne dois pas
toucher ?</para>
</question>
<answer>
<para>Tous les fichiers immédiatement dans
<filename>ports/</filename>, et tous les fichiers des
sous-répertoires dont le nom commence par une majuscule
(<filename>Mk</filename>, <filename>Tools</filename>, etc.). Le
responsable des logiciels est particulièrement susceptible pour
ce qui touche à <filename>ports/Mk/bsd.port.mk</filename>, n'y
touchez donc pas à moins que vous ne vouliez affronter son
courroux.</para>
</answer>
</qandaentry>
</qandadiv>
</qandaset>
</sect1>
</article>
|