Mitja Muženič nous a envoyé une belle histoire à propos du cycle de développement d’OpenBSD, et la voici donc…

A chaque nouvelle version, de plus en plus de nouveaux utilisateurs sont attirés par Puffy, et ils ont à chaque fois des questions concernant le cycle et le processus de développement d’OpenBSD. Bien que cela soit déjà bien documenté dans la FAQ, voyons un peu comment on en arrive à la naissance d’une nouvelle version.

Le cycle de développement commence immédiatement après la sortie de la dernière version (en fait un peu plus tôt comme nous le verrons). Le principal endroit où se passe le travail de développement est le dépôt central du code source du projet, qui est un dépôt CVS. Les développeurs enregistrent (commit) leur travail sur le dépôt CVS à fin de sauvegarde et de distribution, et le code résultant de ces opérations est appelé OpenBSD-current. C’est là que se fait tout le travail de développement. -current, c’est la pointe de la technologie. C’est également une cible mouvante, avec une moyenne de 40 commits par jour, et les modifications apportées peuvent varier d’assez trivial à très complexe. Néanmoins, l’arbre des sources n’est jamais cassé de manière intentionnelle ; si une modification casse la compilation, elle est immédiatement corrigée ou
annulée. Pourquoi ? La raison en est simple : sur la majorité des plateformes supportées, le système est reconstruit en entier tous les quelques jours pour vérifier que tout compile et fonctionne correctement. Ces versions sont alors appelées snapshots (instantanés). Les snapshots constituent une part importante du processus de test global. Ils constituent également un bon moyen de suivre le développement sans avoir à trop se salir les mains – par une simple mise à jour binaire d’un snapshot à un autre on peut se faire une idée de ce que donnera la prochaine version, et on peut aider les développeurs dans leur travail via les rapports de bugs.

OpenBSD sort deux versions par an : une le 1er Mai et l’autre le 1er Novembre. Les quatre mois qui suivent la sortie d’une version sont dédiés au développement et les deux autres mois de chaque cycle sont utilisés pour d’une part stabiliser le code et d’autre part la construction de la version à proprement parler. Habituellement, le gros des changements majeurs se passe au début du cycle, souvent au cours d’un hackathon, de façon à ce qu’il y ait suffisamment de temps pour ajouter de nouvelles fonctionnalités et procéder à diverses améliorations. A mi-cycle environ, le travail se tourne d’une part vers la correction des bugs (moins glamour) et d’autre part vers le nettoyage et la stabilisation générale du code. Environ dix semaines avant la date de sortie de la version, on passe en softlock. C’est le moment d’apporter les retouches finales au code qui sera bientôt finalisé. Les commits sont relus avec attention, et se font de plus en plus rares jusqu’à ce qu’on en arrive au verrouillage complet (full lock) de l’arbre des sources, où plus rien n’est ajouté. A ce moment, le code est gelé, et on procède à la construction et à la vérification des versions pour chaque architecture. Enfin, les fichiers de la version sont envoyés à l’usine de fabrication des CDROM un bon mois avant la sortie. L’arbre des sources est alors déverrouillé et les développeurs repartent pour un nouveau cycle de développement, qui commence à la publication réelle de la version. -current et les snapshots qui lui sont associés sont déjà loin devant, roulant à pleine vapeur.

Quand se rapproche la date de sortie d’une version, les serveurs FTP miroirs dispersés sur toute la planète reçoivent les versions complètes, et les CDROM sortent de l’usine pour arriver chez les distributeurs principaux d’OpenBSD. Les CDROM arrivent généralement en avance, de telle manière qu’ils sont envoyés en avant première aux personnes ayant réservé à l’avance. Comment pourrait-on mieux remercier ceux qui en payant à l’avance ont aidé à couvrir les frais de fabrication des CDROM ?

Enfin arrive le jour de la sortie, avec l’annonce traditionnelle sur les listes de diffusion. Sur les serveurs FTP miroirs, les dossiers contenant la nouvelle version sont dévoilés au public, et c’est par ailleurs le jour de la publication officielle des CDROM. Mais cela ne s’arrête pas là : dans CVS, on voit la création d’une nouvelle branche, nommée -stable. Pour les douze mois à venir, tous les correctifs de sécurité et de stabilité de -current seront rapatriés vers la version -stable du code venant juste d’être publié.

Au moment où j’écris ces lignes, nous approchons de la date de sortie d’OpenBSD 4.4, et les réservations sont déjà ouvertes. Si vous voulez aider à financer cette version et le travail pour celles à venir, réservez (international, Europe) dès maintenant !