POSS Chap 7 Part 3
Un article de Framalang Wiki.
Sommaire |
[modifier] Stabilizing a Release / Stabiliser une version
Stabilization is the process of getting a release branch into a releasable state; that is, of deciding which changes will be in the release, which will not, and shaping the branch content accordingly.
La stabilisation consiste à rendre publiable une branche, c'est à dire décider des changements qui seront inclus dans cette version et ainsi élaborer son contenu.
There's a lot of potential grief contained in that word, "deciding". The last-minute feature rush is a familiar phenomenon in collaborative software projects: as soon as developers see that a release is about to happen, they scramble to finish their current changes, in order not to miss the boat. This, of course, is the exact opposite of what you want at release time. It would be much better for people to work on features at a comfortable pace, and not worry too much about whether their changes make it into this release or the next one. The more changes one tries to cram into a release at the last minute, the more the code is destabilized, and (usually) the more new bugs are created.
Le terme « décider » est polémique. La course à la fonctionnalité de dernière minute est une phénomène courant pour les projets de logiciels collaboratifs : aussitôt que les développeurs s'aperçoivent qu'une sortie est imminente, ils se bousculent pour terminer leur travaux en cours pour ne pas rater le train. C'est évidemment tout ce que vous voulez éviter au moment de sortir une nouvelle version. Il serait nettement préférable qu'ils continuent à travailler sur ces fonctionnalités à leur rythme sans se préoccuper du fait que leurs modifications soient prises en compte dans la version à venir ou dans la suivante. Plus vous essaierez de bourrer une version à la dernière minute, plus le code sera instable et plus vous introduirez de bogues.
Most software engineers agree in theory on rough criteria for what changes should be allowed into a release line during its stabilization period. Obviously, fixes for severe bugs can go in, especially for bugs without workarounds. Documentation updates are fine, as are fixes to error messages (except when they are considered part of the interface and must remain stable). Many projects also allow certain kinds of low-risk or non-core changes to go in during stabilization, and may have formal guidelines for measuring risk. But no amount of formalization can obviate the need for human judgement. There will always be cases where the project simply has to make a decision about whether a given change can go into a release. The danger is that since each person wants to see their own favorite changes admitted into the release, then there will be plenty of people motivated to allow changes, and not enough people motivated to bar them.
La plupart des ingénieurs logiciels s'accordent sur des critères de base permettant de décider quels types de changements devraient être autorisés lors de la période de stabilisation d'une version. Bien sûr les correctifs de bogues graves sont autorisés, en particulier ceux qui ne possèdent pas de contournements. Les mises à jour de la documentation sont acceptables, tout comme les corrections de messages d'erreur (sauf lorsqu'ils sont considérés comme faisant partie de l'interface et doivent rester stables). De nombreux projets autorisent également durant la stabilisation certains changements peu risqués ou sans impact sur le cœur du programme et peuvent avoir des critères stricts pour mesurer les risques. Mais quelque soit le niveau de formalisation, le jugement humain reste indispensable. Il reste toujours des cas où le projet doit prendre la décision d'accepter ou non un changement. Comme chacun souhaite voir ses modifications préférées admises dans la version, il y a de nombreuses personnes motivées pour autoriser les modifications et pas suffisamment pour les bloquer, voilà le risque.
Thus, the process of stabilizing a release is mostly about creating mechanisms for saying "no". The trick for Open Source projects, in particular, is to come up with ways of saying "no" that won't result in too many hurt feelings or disappointed developers, and also won't prevent deserving changes from getting into the release. There are many different ways to do this. It's pretty easy to design systems that satisfy these criteria, once the team has focused on them as the important criteria. Here I'll briefly describe two of the most popular systems, at the extreme ends of the spectrum, but don't let that discourage your project from being creative. Plenty of other arrangements are possible; these are just two that I've seen work in practice.
Par conséquent, le processus de stabilisation d'une version fonctionne principalement par le « non ». La difficulté, en particulier pour les projets libres, est de trouver la manière de refuser tout en évitant de blesser ou de décevoir les développeurs et sans pour autant poser d'entraves aux modifications méritant d'être inclues. Différents moyens le permettent et il est assez simple de créer des systèmes qui satisfassent à ces critères une fois que l'équipe les a identifiés. Je ferai ici une brève description de deux des systèmes parmi les plus populaires tout en étant diamétralement opposés, mais n'hésitez pas à vous monter plus créatif : de nombreuses autres possibilités existent, il s'agit de deux exemples simples dont j'ai pu constater l'efficacité en pratique.
[modifier] Dictatorship by Release Owner / La dictature du propriétaire de version
The group agrees to let one person be the release owner. This person has final say over what changes make it into the release. Of course, it is normal and expected for there to be discussions and arguments, but in the end the group must grant the release owner sufficient authority to make final decisions. For this system to work, it is necessary to choose someone with the technical competence to understand all the changes, and the social standing and people skills to navigate the discussions leading up to the release without causing too many hurt feelings.
Le groupe désigne un propriétaire de version. Cette personne conserve le dernier mot sur les changements qui seront inclus ou non dans la version. Bien sûr, il est normal et attendu qu'il y ait des discussions et des débats mais le groupe doit au final accorder une autorité suffisante au propriétaire de version pour qu'il prenne les décisions finales. Pour que ce système fonctionne, la personne choisie doit d'une part disposer des compétences techniques requises pour comprendre toutes les modifications et d'autre part avoir le charisme ainsi que les compétences interpersonnelles nécessaires pour mener la discussion et aboutir à la publication sans froisser excessivement les susceptibilités.
A common pattern is for the release owner to say "I don't think there's anything wrong with this change, but we haven't had enough time to test it yet, so it shouldn't go into this release." It helps a lot if the release owner has broad technical knowledge of the project, and can give reasons why the change could be potentially destabilizing (for example, its interactions with other parts of the software, or portability concerns). People will sometimes ask such decisions to be justified, or will argue that a change is not as risky as it looks. These conversations need not be confrontational, as long as the release owner is able to consider all the arguments objectively and not reflexively dig in his heels.
Une affirmation courante du propriétaire de version est par exemple « Je ne pense pas qu'il y ait de problème avec cette modification, mais nous n'avons pas assez de temps pour la tester maintenant, on ne devrait donc pas l'inclure dans cette version ». S'il possède une connaissance technique générale du projet, il est judicieux de sa part d'expliquer en quoi le changement pourrait impacter la version (par exemple, par ses interactions avec d'autres parties du logiciel, ou pour une question de portabilité). Les gens demanderont parfois des justifications ou affirmeront que leur modifications ne sont pas si risquées. Ces conversations ne seront pas conflictuelles tant que le propriétaire de version sera en mesure de peser tous les arguments, objectivement et sans camper systématiquement sur ses positions.
Note that the release owner need not be the same person as the project leader (in cases where there is a project leader at all; see the section called “Benevolent Dictators” in Chapter 4, Social and Political Infrastructure). In fact, sometimes it's good to make sure they're not the same person. The skills that make a good development leader are not necessarily the same as those that make a good release owner. In something as important as the release process, it may be wise to have someone provide a counterbalance to the project leader's judgement.
Contrast the release owner role with the less dictatorial role described in the section called “Release manager” later in this chapter.Notez que le propriétaire de version n'est pas nécessairement le chef du projet (s'il y en a un, voir la section « Les dictateurs bienveillants » du Chapitre 4, Infrastructure politique et sociale). Il est souvent préférable que ces deux personnes soient différentes. Les aptitudes requises par ces deux rôles sont assurément différentes. Pour quelque chose d'aussi important que le processus de publication il est sage d'apporter un contre poids au jugement du chef de projet.
Comparez le rôle du propriétaire de version à celui, moins dictatorial, décrit dans la section « Contrôleur de version » plus loin dans ce chapitre.[modifier] Change Voting / Le choix des évolutions par vote
At the opposite extreme from dictatorship by release owner, developers can simply vote on which changes to include in the release. However, since the most important function of release stabilization is to exclude changes, it's important to design the voting system in such a way that getting a change into the release involves positive action by multiple developers. Including a change should need more than just a simple majority (see the section called “Who Votes?” in Chapter 4, Social and Political Infrastructure). Otherwise, one vote for and none against a given change would suffice to get it into the release, and an unfortunate dynamic would be set up whereby each developer would vote for her own changes, yet would be reluctant to vote against others' changes, for fear of possible retaliation. To avoid this, the system should be arranged such that subgroups of developers must act in cooperation to get any change into the release. This not only means that more people review each change, it also makes any individual developer less hesitant to vote against a change, because she knows that no particular one among those who voted for it would take her vote against as a personal affront. The greater the number of people involved, the more the discussion becomes about the change and less about the individuals.
A l'extrême opposé du concept de dictature du propriétaire de version, les développeurs peuvent simplement voter pour décider quelles évolutions sont à inclure dans la version. Cependant, la fonction la plus importante de la stabilisation étant d'exclure la majorité des changements il est important de concevoir le système de vote avec en tête que l'ajout de modifications doit exiger une action positive de la part de plusieurs développeurs. Un ajout ne devrait pas se contenter d'une simple majorité (voir la section « Qui vote? » dans le Chapitre 4, Infrastructure sociale et politique). Dans le cas contraire, un vote « pour » et aucun vote « contre » une modification suffirait à la valider et une dynamique indésirable se mettrait en place : chaque développeur voterait pour son propre changement et serait peu enclin à voter contre les modifications des autres, par peur de représailles. Afin d'éviter cela, le système devrait favoriser la coopération entre sous-groupes de développeurs militants pour un changement. Non seulement plus de gens vérifient alors les modifications, mais les développeurs en tant qu'individus sont davantage enclins à voter contre , parce qu'ils savent que personne, en particulier parmi ceux qui ont voté « pour », ne prendra leur vote « contre » comme un affront personnel. Plus il y a de gens impliqués, plus la discussion se focalise sur les changements et non plus les individus.
The system we use in the Subversion project seems to have struck a good balance, so I'll recommend it here. In order for a change to be applied to the release branch, at least three developers must vote in favor of it, and none against. A single "no" vote is enough to stop the change from being included; that is, a "no" vote in a release context is equivalent to a veto (see the section called “Vetoes”). Naturally, any such vote must be accompanied by a justification, and in theory the veto could be overridden if enough people feel it is unreasonable and force a special vote over it. In practice, this has never happened, and I don't expect that it ever will. People are conservative around releases anyway, and when someone feels strongly enough to veto the inclusion of a change, there's usually a good reason for it.
Le système que nous employons dans le projet Subversion semble avoir atteint un bon équilibre, je le recommande donc. Pour qu'une modification soit appliquée à une branche de publication au moins trois développeurs doivent voter en sa faveur et aucun contre. Un seul vote « contre » est suffisant pour que le changement ne soit pas ajouté, c'est à dire qu'un vote « contre » équivaut à un veto (voir la section nommée « Vetos »). Naturellement, un tel vote doit être motivé par une justification et, en théorie, le veto peut être outrepassé si suffisamment de personne pensent qu'il est excessif et forcent un vote spécial pour le contourner. En pratique, ceci ne s'est jamais produit et je ne pense pas qu'on y assistera un jour. Les gens deviennent naturellement plus conservateurs quand on s'approche d'une publication et lorsque quelqu'un est suffisamment déterminé pour opposer son veto à une modification, ses raisons sont généralement bonnes.
Because the release procedure is deliberately biased toward conservatism, the justifications offered for vetoes are sometimes procedural rather than technical. For example, a person may feel that a change is well-written and unlikely to cause any new bugs, but vote against its inclusion in a micro release simply because it's too big—perhaps it adds a new feature, or in some subtle way fails to fully follow the compatibility guidelines. I've occasionally even seen developers veto something because they simply had a gut feeling that the change needed more testing, even though they couldn't spot any bugs in it by inspection. People grumbled a little bit, but the vetoes stood and the change was not included in the release (I don't remember if any bugs were found in later testing or not, though).
La procédure de publication étant délibérément biaisée en faveur du conservatisme, les justifications données pour les vetos sont parfois plus procédurières que techniques. Par exemple, une personne peut être convaincue qu'une modification est correcte et ne causera probablement aucun nouveau bogue et voter pourtant contre son inclusion dans une version de mise à jour intermédiaire simplement parce que cette modification est trop lourde et qu'elle apporte peut-être de nouvelles fonctionnalités ou risque de ne pas remplir totalement les règles de compatibilité ascendantes. J'ai même déjà vu à une occasion des développeurs opposer leur veto simplement au titre d'un pressentiment que la modification nécessitait des tests plus poussés, sans toutefois détecter le moindre bogue lors des relectures. Malgré les récriminations, le veto fut respecté et la modification n'a pas été incluse dans cette version (d'ailleurs je ne me souviens pas si des bogues ont finalement été découverts ou pas).
[modifier] Managing collaborative release stabilization / Gérer une stabilisation collégiale
If your project chooses a change voting system, it is imperative that the physical mechanics of setting up ballots and casting votes be as convenient as possible. Although there is plenty of Open Source electronic voting software available, in practice the easiest thing to do is just to set up a text file in the release branch, called STATUS or VOTES or something like that. This file lists each proposed change—any developer can propose a change for inclusion—along with all the votes for and against it, plus any notes or comments. (Proposing a change doesn't necessarily mean voting for it, by the way, although the two often go together.) An entry in such a file might look like this:
Si votre projet opte pour un système de vote, vous devez rendre aussi accessibles que possible les outils du vote ainsi que le vote en lui-même. Bien qu'il existe de nombreux logiciels Open Source créés pour faciliter le vote électronique, un simple fichier texte (que l'on nommera par exemple « STATUS » ou « VOTES ») dans la branche de publication se révélera plus pratique. Le fichier, éditable par tous les développeurs, liste chaque évolution proposée ainsi que les votes pour ou contre. Les votes sont fréquemment accompagnés de notes et commentaires. Notez que proposer une modification ne signifie pas nécessairement voter pour, bien que les deux aillent souvent de pair. Une entrée dans un tel fichier pourrait ressembler à ceci :
- r2401 (issue #49)
Prevent client/server handshake from happening twice. Justification: Avoids extra network turnaround; small change and easy to review. Notes: This was discussed in http://.../mailing-lists/message-7777.html and other messages in that thread. Votes: +1: jsmith, kimf -1: tmartin (breaks compatibility with some pre-1.0 servers; admittedly, those servers are buggy, but why be incompatible if we don't have to?)
- r2401 (problème #49)
Éviter que la redondance de la connexion client/serveur. Justification : Supprime des accès réseaux inutiles ; changement minime et facile à vérifier. Notes : Sujet discuté sur http://.../mailing-lists/message-7777.html et autres messages dans ce sujet. Votes : +1 : jsmith, kimf -1 : tmartin (viole la compatibilité avec certains serveurs pre-1.0 ; il est vrai que ces serveurs sont bogués, mais il faut préserver la compatibilité tant que possible)
In this case, the change acquired two positive votes, but was vetoed by tmartin, who gave the reason for the veto in a parenthetical note. The exact format of the entry doesn't matter; whatever your project settles on is fine—perhaps tmartin's explanation for the veto should go up in the "Notes:" section, or perhaps the change description should get a "Description:" header to match the other sections. The important thing is that all the information needed to evaluate the change be reachable, and that the mechanism for casting votes be as lightweight as possible. The proposed change is referred to by its revision number in the repository (in this case a single revision, r2401, although a proposed change could just as easily consist of multiple revisions). The revision is assumed to refer to a change made on the trunk; if the change were already on the release branch, there would be no need to vote on it. If your version control system doesn't have an obvious syntax for referring to individual changes, then the project should make one up. For voting to be practical, each change under consideration must be unambiguously identifiable.
Ici, la modification a reçu deux votes pour mais « tmartin » a opposé son veto et l'a justifié dans une note entre parenthèses. La forme exacte de cette entrée est sans importance : l'explication de « tmartin » pourrait se trouver dans la section « Notes » ou la description de la modification marquée par un titre « Description » pour correspondre aux autres sections... Il faut principalement vous assurez que toutes les informations nécessaires à l'évaluation soit disponibles et que le système de vote est aussi simple que possible. La modification soumise à débat est désignée par son numéro de révision dans le dépôt de sources (dans ce cas, il contient une seule révision, la r2401, mais une modification peut en référencer plusieurs). La révision pointe implicitement vers un changement du tronc puisqu'une modification issue de la branche de publication n'aurait pas eu à être soumise au vote. Si votre logiciel de gestion de version ne dispose pas d'une syntaxe explicite pour se référer à des modifications individuelles alors le projet devrait en prévoir une. Pour que le vote soit fonctionnel, chaque modification doit être identifiable sans ambiguïté.
Those proposing or voting for a change are responsible for making sure it applies cleanly to the release branch, that is, applies without conflicts (see conflict). If there are conflicts, then the entry should either point to an adjusted patch that does apply cleanly, or to a temporary branch that holds an adjusted version of the change, for example:
- r13222, r13223, r13232
Rewrite libsvn_fs_fs's auto-merge algorithm Justification: unacceptable performance (>50 minutes for a small commit) in a repository with 300,000 revisions Branch: 1.1.x-r13222@13517 Votes: +1: epg, ghudson
Ceux qui ont proposé ou voté pour une modification doivent s'assurer que cette dernière s'applique correctement et sans conflit à la branche de publication (voir Conflits). Si des conflits subsistent la modification doit pointer vers un correctif ou vers une branche temporaire proposant une version ajustée de la modification, par exemple :
- r13222, r13223, r13232
Réécrire l'algorithme de fusion automatique libsvn_fs_fs
Justification :
Performances inacceptables (>50 minutes pour un petit ajout) dans
un dépôt contenant 300 000 révisions
Branche :
1.1.x-r13222@13517
Votes :
+1 : epg, ghudson
That example is taken from real life; it comes from the STATUS file for the Subversion 1.1.4 release process. Notice how it uses the original revisions as canonical handles on the change, even though there is also a branch with a conflict-adjusted version of the change (the branch also combines the three trunk revisions into one, r13517, to make it easier to merge the change into the release, should it get approval). The original revisions are provided because they're still the easiest entity to review, since they have the original log messages. The temporary branch wouldn't have those log messages; in order to avoid duplication of information (see the section called “Singularity of information” in Chapter 3, Technical Infrastructure), the branch's log message for r13517 should simply say "Adjust r13222, r13223, and r13232 for backport to 1.1.x branch." All other information about the changes can be chased down at their original revisions.
Cet exemple est authentique et provient du fichier « STATUS » utilisé lors de la publication de Subversion 1.1.4. Notez qu'il utilise les révisions originales comme identifiants uniques des modifications, malgré l'utilisation d'une branche contenant une version adaptée de la modification (la branche combine les trois révisions du tronc en une seule, la r13517, afin de faciliter sa fusion si elle est acceptée). Les révisions originales sont présentent pour faciliter leur consultation car les commentaires originaux y sont liés. La branche temporaire ne doit pas reprendre ces derniers pour éviter de dupliquer l'information (voir la section « Unicité de l'information » dans la Chapitre 3, Infrastructure Technique), le commentaire de la révision r13517 devrait simplement contenir « Ajuster r13222, r13223 et r12232 pour portage à la branche 1.1.x. ». Toute autre information peut être retrouvée dans les révisions originales.
[modifier] Release manager / Le responsable de version
The actual process of merging (see merge (a.k.a. port)) approved changes into the release branch can be performed by any developer. There does not need to be one person whose job it is to merge changes; if there are a lot of changes, it can be better to spread the burden around.
La fusion (voir fusion ou portage) des modifications approuvées vers la branche de publication peut être effectuée par les différents développeurs. Un poste spécifique dédié aux fusions n'est pas indispensable. Si elles se multiplient, mieux vaut répartir la charge de travail entre plusieurs développeurs.
However, although both voting and merging happen in a decentralized fashion, in practice there are usually one or two people driving the release process. This role is sometimes formally blessed as release manager, but it is quite different from a release owner (see the section called “Dictatorship by Release Owner” earlier in this chapter) who has final say over the changes. Release managers keep track of how many changes are currently under consideration, how many have been approved, how many seem likely to be approved, etc. If they sense that important changes are not getting enough attention, and might be left out of the release for lack of votes, they will gently nag other developers to review and vote. When a batch of changes are approved, these people will often take it upon themselves to merge them into the release branch; it's fine if others leave that task to them, as long as everyone understands that they are not obligated to do all the work unless they have explicitly committed to it. When the time comes to put the release out the door (see the section called “Testing and Releasing” later in this chapter), the release managers also take care of the logistics of creating the final release packages, collecting digital signatures, uploading the packages, and making the public announcement.
Malgré le caractère décentralisé des votes et des fusions, une ou deux personnes guident dans la pratique le processus de publication. On utilise parfois le terme formel de « responsable de version » pour ce rôle sensiblement différent du « propriétaire de version » (voir la section « La dictature du propriétaire de version » précédemment dans ce chapitre) qui garde le dernier mot sur les changements à appliquer. Les responsables de version effectuent le suivi des modifications actuellement en cours de traitement : combien ont été approuvées, combien sont en voie d'obtenir l'approbation, etc... S'ils considèrent que des changements importants n'attirent pas suffisamment l'attention et pourraient se retrouver absents de la version par manque de vote, ils suggèrent subtilement aux développeurs de les examiner et de s'y intéresser. Lorsqu'un lot de modifications est approuvé, ils se chargent (en général de leur propre initiative) de les insérer dans la branche de publication. Les autres développeurs doivent cependant comprendre que tout ce travail n'incombe pas aux seuls responsables de version, sauf prérogatives explicites. Lors de la publication de la version (voir la section « Tests et sortie » plus loin dans ce chapitre), les responsables de version sont également responsables de la création des paquets définitifs, de la collecte des signatures numériques, de la mise à disposition des paquets et d'en faire l'annonce publique.
