Une fois n’est pas coutume, ce post sera également en Anglais. Je suis certain que le sujet ne manquera d’intéresser des lecteurs non francophones.

Il y a quelques semaines, iMil et moi lançions l’idée d’interviewer des développeurs NetBSD pour faire le projet et leur travail, un peu à la manière de BSDTalk.

Aussitôt dit, aussitôt fait, après un rapide brainstorming sur le canal, voici le premier interview de la série « Discussions avec un développeur NetBSD ».

Soren Jacobsen répond à nos questions.

NetBSDfr: Avant de commencer, je voudrais te remercier d’avoir
accepté de répondre à nos questions. Nous espérons interviewer
plusieurs développeurs du projet NetBSD, au rythme d’un tous
les 1 ou 2 mois. Tu as été choisi pour ce premier épisode.
Merci d’avoir accepté de répondre à nos questions.

snj:Merci de m’avoir interrogé, et merci pour vos efforts pour
faire vivre la communauté. C’est super de voir de telles initiatives.
Je suis navré d’avoir mis aussi longtemps à te répondre. Je voulais
prendre le temps de réfléchir à mes réponses. Merci de me dire si
certains points nécessitent des clarifications.

NetBSDfr: Pour nos lecteurs qui ne te connaissent pas, peux-tu te
présenter rapidement ?

snj: Je m’appele Soren Jacobsen, je suis développeur NetBSD et
« release manager ». Je fais partie de l’équipe « release engineering »
- releng – depuis 2005, et j’ai été le release engineer principal
de NetBSD 5.0.

NetBSDfr: Quelles sont les raisons qui t’ont amené à choisir
NetBSD ? Depuis combien de temps utilises-tu ce système ?

snj: Ma première expérience avec NetBSD remonte à la version 1.5.3,
mi-2002. A ce moment-là, plusieurs choses sous Linux me frustraient,
et NetBSD était un système d’exploitation solide avec une
philosophie qui me plaisait. Il n’y avait pas de raisons
particulières qui m’ont amené à NetBSD, mais plutôt que rien ne me
 déplaisait. Cà semblait juste parfait.

NetBSDfr: As-tu une idée du temps que tu consacres au projet NetBSD
chaque jour ? chaque semaine ? chaque mois ?

snj: Comme beaucoup de volontaires, le temps que je peux accorder
au projet dépend beaucoup de mes occupations de tous les jours et de
mon niveau de motivation.Il y a un an, au plus je consacrais 8
heures par semaine au projet. Plus récemment, 8 heures par jour
était assez courant.
La semaine de la release a été particulièrement trépidante:
plusieurs fois, j’ai consacré 16 heures par jour au projet.

NetBSDfr: Comment es-tu devenu développeur NetBSD ?

snj: Quand j’ai commencé à utiliser NetBSD comme système
d’exploitation principal, je suis devenu fortement dépendant de
pkgsrc, notre framework pour les paquets tiers. Il y avait un
certain nombre de paquets que je souhaitais voir mis à jour, et
j’ai commencé à envoyer des patches pour pkgsrc, et diverses petites
choses dans le système de base. Fin 2003, on m’a proposé un @, et
je suis devenu développeur du projet en Janvier 2004.

A tous ceux qui sont intéressés pour aider le projet: pkgsrc est un
très bon moyen de s’impliquer. Il y a un très grand nombre de
packages disponibles, et un nombre de développeurs limité pour les
importer et les maintenir.
N’hésitez pas à envoyer des rapports de bugs pour les paquets que
vous utilisez, et rejoignez le projet pkgsrc-wip.
Toute l’aide que vous pourrez apporter sera la bienvenue.

NetBSDfr: Comment es-tu devenu membre de l’équipe « release
engineering » ? Comment celle-ci fonctionne-t-elle ? Les
membres de l’équipe sont-ils élus ? choisis ? Quelles sont les
compétences requises ?

snj: L’équipe release engineering est plutôt informelle. Il n’y a
pas d’élections, et pas de leader clairement identifié, même si des
personnes s’imposent dans ce rôle. Quand nous pensons que l’équipe
manque de monde, nous faisons un appel à volontaire, et en règle
générale, une ou deux personnes nous rejoignent.
Mais release engineering est une activité moins « glorieuse » que
beaucoup d’autres, et la plupart du temps, les gens ne se battent
pas pour nous rejoindre.
Difficile de parler de compétences spécifiques. Comme dans beaucoup
d’autres cas, un bon sens de la perspective et de jugement sont
indispensables. Ce sont les deux seules compétences strictement
requises. Toutefois, bien d’autres choses utiles: la patience,
la prudence, le sens du détail… Rien de très extraordinaire.
Bien évidemment, plus votre bagage technique est important, mieux
c’est. Mais çà n’est pas aussi important que l’on pourrait le
croire. J’y reviendrai après.

NetBSDfr: Peux-tu nous expliquer en détails comment fonctionne le
process de « release engineering » de NetBSD ?

snj: Il y a deux tâches principales:

• propager des changements dans les branches du code.
• Sortir une nouvelle version du système (‘releasing’).

La première est assez simple, et c’est quelque chose que nous
faisons constamment. Les développeurs demandent à ce que certains
changements soient propagés dans une branche donnée. Si nous sommes
d’accord avec ces changements, ils sont commités dans la branche.
Afin de pouvoir suivre l’évolution d’une branche, nous maintenons
une trace de tous les changements apportés à une branche au cours
de sa vie.

Construire une nouvelle version de NetBSD est une tâche bien plus
complexe, qui demande la coordination d’un très grand nombre de
personnes. La principale tâche consiste à décider à partir de quel
moment les bugs restants peuvent être ignorés sans risques. Il y
a bien entendu bien d’autres activités qui interviennent ici:
s’occuper du cluster de construction, propager les changements,
préparer les informations à propos de la release, tester,
s’assurer que les corrections de bugs importants ont été intégrées
à la branche, prier les gens de travailler sur certains sujets,
suivre avec une attention particulière les mailing-lists…

NetBSDfr: Comment fonctionner le process d’assurance qualité ?
Qui décide de propager tel ou tel patch dans une branche ?
Une question liée à celles-ci est la suivante: comment la releng
team décide-t-elle du nombre de pré-versions nécessaires avant de
déclarer qu’une branche est stable ?

snj: Une seule personne ne peut pas avoir une vision technique
complète et pertinente sur tous les aspects du code source. Aussi,
il est parfois difficile d’affirmer avec certitude qu’un changement
doit être propagé dans une branche. C’est à cet instant qu’une des
qualités les plus importantes d’un release engineer intervient: la
capacité à demander à la bonne personne. Nous faisons confiance aux
développeurs qui demandent à propager des changements pour avoir
soigneusement mesurer les implications du changement. Mais en même
temps, nous essayons d’être extrêmement prudents, et être capables
de discuter avec d’autres développeurs est d’une importance vitale.
Le process de release commence lorsque nous pensons l’arbre des
sources est assez stable.
A cet instant, la branche s’appelle, par exemple, 5.0_BETA. De plus en
plus d’utilisateurs vont tester cette version, et nous cherchons
constamment du feedback, positif ou négatif. Durant toutes les phases
du release process, nous évitons les changements intrusifs. Toutefois,
ils sont encore acceptés à ce stade. La règle générale veut que plus le
release process avance, plus nous sommes restrictifs sur les changements.
Toutefois, rien n’est figé de manière absolue. Si un énorme bug
apparaît, vous avez le choix entre ignorer le problème et prendre le
risque d’un changement intrusif. Parfois, nous prenons le risque, parfois
non. C’est encore un exemple de cas ou une seule personne ne peut pas
avoir toutes les réponses. Afin d’éviter une erreur de jugement, les
membres de la releng team discutent de ces problèmes entre eux et
avec d’autres développeurs.
Une « release candidate », est, par définition, le moment ou l’arbre de
source est dans un état publiable. En pratique, celà arrive rarement. Il y
a presque toujours au moins une « release candidate » de plus. D’une
certaine manière, c’est plus psychologique qu’autre chose.

Je reconnais que j’ai taggué une paire de releases candidates, en
sachant parfaitement que 5.0 ne pourrait pas être releasé en l’état.

Mais quand d’importants changements de dernière minutes sont
introduits dans une branche, une release candidate est le meilleur
moyen que ces changements soient testés largement.

Prenons 5.0_RC3 par exemple. Au moment de cette RC, nous savions
parfaitement qu’il restait quelques bugs qui empêchait la release, mais
il y avait eu en parallèle d’importants changements autour de WAPBL
qui demandaient des tests plus nombreux. Donc, RC3 avait sa justification.

Finalement, une release est toujours affaire de compromis. D’un côté,
vous avez une liste de pré-requis que la nouvelle version doit remplir.
De l’autre, vous avez atteint un point où les bugs restants sont
compensés par toutes les nouvelles fonctionnalités apportées par la
nouvelle version.
C’est souvent quelque chose de difficile. Quand on a passé des mois à
traquer chacuns des problèmes, on a tendance à être omnubilé par les
aspects négatifs, jusqu’à en oublier tous les plus apporter par la
nouvelle version et les bonnes expériences des gens.

En fait, il faut accepter qu’une version exempte de bugs est un objectif
impossible à atteindre. Quand on a atteint ce stade, on taggue la
release finale, et on espère n’avoir pas commis une irréparable erreur.

NetBSDfr: Pour conclure, peux-tu nous dire comment tu entrevois le
futur de NetBSD ?

snj: Nous avons fait un énorme saut en avant avec NetBSD 5.0, et la
tendance va continuer avec 6.0.
NetBSD a été ignoré de beaucoup de gens pendant des années, mais
c’est en train de changer.
Plus précisément, je pense que l’usage de NetBSD va considérablement
augmenter dans les environnements serveurs et embarqués. Je
n’entrevois pas de changement radical dans la direction du projet, mais
çà n’est pas un problème. NetBSD a toujours été un bon système
d’exploitation. Nous devons juste sortir de l’ombre et faire connaître
le système au plus grand nombre.

Rendez-vous dans quelques semaines pour une nouvelle interview. D’ici là, si vous avez des idéesde personnes à interviewer et de questions à poser, n’hésitez pas!