4. Relations entre développeurs

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 liste de diffusion des messages de modification CVS de FreeBSD 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 committer. Pour les logiciels portés, vous devriez contacter la personne listée comme MAINTAINER dans le Makefile. 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 cvs log 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.

Si vous avez pour une raison ou une autre des doutes à propos d'une soumission que vous envisagez, faites-la d'abord examiner par -hackers 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.