POSS Chap 7 Part 7
Un article de Framalang Wiki.
[modifier] Releases and Daily Development / Publications et développement au quotidien
Maintaining parallel releases simultaneously has implications for how daily development is done. In particular, it makes practically mandatory a discipline that would be recommended anyway: have each commit be a single logical change, and never mix unrelated changes in the same commit. If a change is too big or too disruptive to do in one commit, break it across N commits, where each commit is a well-partitioned subset of the overall change, and includes nothing unrelated to the overall change.
Le maintien de plusieurs versions simultanées a des impacts sur le développement au quotidien. En particulier, cela rend presque obligatoire une discipline (recommandée de toute manière) : que chaque modification n'apporte qu'un changement à la fois et que des changements isolés ne soient jamais mélangés au sein d'un même commit. Si un changement est trop important ou trop impactant, il est conseillé de l'éclater en plusieurs commits plus petits, chacun étant une sous partie bien délimitée et n'embarquant rien qui ne soit relatif au changement global.
Here's an example of an ill-thought-out commit:
r6228 / jrandom / 2004-06-30 22:13:07 -0500 (Wed, 30 Jun 2004) / 8 lines
Fix Issue #1729: Make indexing gracefully warn the user when a file is changing as it is being indexed.
- ui/repl.py
(ChangingFile): New exception class. (DoIndex): Handle new exception.
- indexer/index.py
(FollowStream): Raise new exception if file changes during indexing. (BuildDir): Unrelatedly, remove some obsolete comments, reformat some code, and fix the error check when creating a directory.
Other unrelated cleanups:
- www/index.html: Fix some typos, set next release date.
Voici un exemple de modification mal conçue :
r6228 / toto / 30-06-2004 22:13:07 -0500 (Mercredi, 30 juin 2004) / 8 lignes Corrige le problème #1729 : Faire que l'indexation avertisse l'utilisateur quand un fichier est modifié lors de son indexation.
- ui/repl.py
(ChangingFile) : Nouvelle classe d'exception. (DoIndex) : Prise en charge de la nouvelle exception.
- indexer/index.py
(FollowStream) : Afficher une nouvelle exception si un fichier change durant l'indexation. (BuildDir) : Sans lien, retire des commentaires devenus obsolètes, refonte d'une partie du code et corrige le vérificateur d'erreurs lors de la création d'un répertoire.
Autres nettoyages sans lien :
- www/index.html : Correction de quelques coquilles, date de la prochaine mise à jour établie.
The problem with it becomes apparent as soon as someone needs to port the BuildDir error check fix over to a branch for an upcoming maintenance release. The porter doesn't want any of the other changes—for example, perhaps the fix to issue #1729 wasn't approved for the maintenance branch at all, and the index.html tweaks would simply be irrelevant there. But she cannot easily grab just the BuildDir change via the version control tool's merge functionality, because the version control system was told that that change is logically grouped with all these other unrelated things. In fact, the problem would become apparent even before the merge. Merely listing the change for voting would become problematic: instead of just giving the revision number, the proposer would have to make a special patch or change branch just to isolate the portion of the commit being proposed. That would be a lot of work for others to suffer through, and all because the original committer couldn't be bothered to break things into logical groups.
Le problème apparaît dès que quelqu'un veut transposer le correctif portant sur le vérificateur d'erreur BuildDir dans une branche de maintenance. La personne s'en chargeant ne désire pas les autres modifications : le correctif du problème #1729 peut ne pas avoir été approuvé pour la branche de maintenance et les améliorations de index.html sont ici sans objet. Mais il ne peut pas facilement extraire la modification apportée à BuildDir grâce aux outils de fusion du logiciel de gestion de version puisque la modification groupe logiquement diverses modifications sans rapport. En fait, le problème serait visible avant même la fusion. Le simple fait de lister la modification pour la soumettre au vote serait problématique : au lieu de simplement fournir le numéro de révision, la personne qui propose le vote devrait préparer un correctif spécial ou changer de branche simplement pour isoler la partie du changement qu'il désire faire valider. Tout ceci rend le travail des autres plus difficile, uniquement parce que celui qui a enregistré ces modifications n'a pas pris la peine de les séparer en des groupes logiques isolés.
In fact, that commit really should have been four separate commits: one to fix issue #1729, another to remove obsolete comments and reformat code in BuildDir, another to fix the error check in BuildDir, and finally, one to tweak index.html. The third of those commits would be the one proposed for the maintenance release branch.
Concrètement, ce commit unique auraient dû être séparé en quatre commits distincts : un pour le problème #1729, un autre pour retirer les commentaires devenus obsolètes et reformater le code dans BuildDir, un autre pour réparer la vérification d'erreurs dans BuildDir et le dernier portant sur les améliorations de index.html. Le changement proposé pour la branche de la version de maintenance aurait été le troisième.
Of course, release stabilization is not the only reason why having each commit be one logical change is desirable. Psychologically, a semantically unified commit is easier to review, and easier to revert if necessary (in some version control systems, reversion is really a special kind of merge anyway). A little up-front discipline on everyone's part can save the project a lot of headache later.
Les changements doivent être atomiques et pas seulement lors de la période de stabilisation pré-publication. Psychologiquement, un changement unifié autour d'un thème précis est plus facile à vérifier et à annuler si nécessaire (dans certains logiciels de gestion de version, l'annulation est en fait un type particulier de fusion). Un peu de discipline de chacun évitera plus tard beaucoup de problèmes au projet.
[modifier] Planning Releases / Planifier les publications
One area where Open Source projects have historically differed from proprietary projects is in release planning. Proprietary projects usually have firmer deadlines. Sometimes it's because customers were promised that an upgrade would be available by a certain date, because the new release needs to be coordinated with some other effort for marketing purposes, or because the venture capitalists who invested in the whole thing need to see some results before they put in any more funding. Free software projects, on the other hand, were until recently mostly motivated by amateurism in the most literal sense: they were written for the love of it. No one felt the need to ship before all the features were ready, and why should they? It wasn't as if anyone's job was on the line.
L'un des domaines dans lequel les projets Open Source diffèrent historiquement des projets propriétaires est celui de la planification des publications. Les projets propriétaires ont en général des dates butoirs bien définies. Parfois parce qu'on a promis aux clients une mise à jour à une date précise, parce que la nouvelle version doit être coordonnée avec d'autres actions liées aux marketing ou parce que les partenaires financiers qui ont investi dans le projet demandent à voir des résultats avant de s'engager plus en avant. Les projets de logiciels libres, d'un autre côté, étaient encore récemment motivés principalement par l'« amateurisme » pris dans son sens le plus littéral : les développeurs écrivaient simplement par plaisir. Personne ne ressentait l'obligation de livrer le produit avant que toutes les fonctionnalités ne soient prêtes et d'ailleurs pourquoi auraient-ils dû le faire ? Ce n'était pas comme si l'emploi de quelqu'un était en jeu.
Nowadays, many Open Source projects are funded by corporations, and are correspondingly more and more influenced by deadline-conscious corporate culture. This is in many ways a good thing, but it can cause conflicts between the priorities of those developers who are being paid and those who are volunteering their time. These conflicts often happen around the issue of when and how to schedule releases. The salaried developers who are under pressure will naturally want to just pick a date when the releases will occur, and have everyone's activities fall into line. But the volunteers may have other agendas—perhaps features they want to complete, or some testing they want to have done—that they feel the release should wait on.
De nos jours, de nombreux projets libres sont financés par de grands groupes et sont donc de plus en plus influencés par le concept de dates butoirs hérité de la culture d'entreprise. C'est positif à bien des égards, mais cela peut créer des conflits entre les priorités des développeurs rémunérés et bénévoles. La question de la date de publication et de son contenu cristallise souvent ces divergences. Les développeurs salariés, sous pression, voudront naturellement choisir une date pour la prochaine version et souhaiterons que l'activité de chacun s'aligne dessus. Mais les volontaires peuvent avoir un autre programme, peut-être des fonctionnalités qu'ils veulent terminer ou quelques tests qu'ils veulent mener à bien, et estimeront donc que la sortie peut attendre.
There is no general solution to this problem except discussion and compromise, of course. But you can minimize the frequency and degree of friction caused, by decoupling the proposed existence of a given release from the date when it would go out the door. That is, try to steer discussion toward the subject of which releases the project will be making in the near- to medium-term future, and what features will be in them, without at first mentioning anything about dates, except for rough guesses with wide margins of error. By nailing down feature sets early, you reduce the complexity of the discussion centered on any individual release, and therefore improve predictability. This also creates a kind of inertial bias against anyone who proposes to expand the definition of a release by adding new features or other complications. If the release's contents are fairly well defined, the onus is on the proposer to justify the expansion, even though the date of the release may not have been set yet.
Il n'existe pas de solution générique à ce problème, sauf évidemment la discussion et le compromis. Mais vous pouvez limiter la fréquence et l'importance des frictions en dissociant l'idée d'une version future de sa date de sortie. Essayez d'orienter la discussion sur les versions à court et moyen terme et sur les fonctionnalités que ces dernières devraient incorporer. N'avancez pas encore de date, sauf pour donner un ordre d'idée et encore avec une grande marge d'erreur. En fixant l'ensemble des fonctionnalités suffisamment tôt vous réduisez la complexité des discussions centrées sur chaque version particulière et donc vous améliorez votre maîtrise du futur. En même temps vous créez une certaine inertie que devra vaincre une personne voulant élargir la définition d'une version en ajoutant de nouvelles fonctionnalités ou complications. Si le périmètre d'une version est bien défini, il appartient à celui qui propose l'élargissement de le justifier, même si la date de publication n'a pas encore été fixée.
In his multi-volume biography of Thomas Jefferson, Jefferson and His Time, Dumas Malone tells the story of how Jefferson handled the first meeting held to decide the organization of the future University of Virginia. The University had been Jefferson's idea in the first place, but (as is the case everywhere, not just in Open Source projects) many other parties had climbed on board quickly, each with their own interests and agendas. When they gathered at that first meeting to hash things out, Jefferson made sure to show up with meticulously prepared architectural drawings, detailed budgets for construction and operation, a proposed curriculum, and the names of specific faculty he wanted to import from Europe. No one else in the room was even remotely as prepared; the group essentially had to capitulate to Jefferson's vision, and the University was eventually founded more or less in accordance with his plans. The facts that construction went far over budget, and that many of his ideas did not, for various reasons, work out in the end, were all things Jefferson probably knew perfectly well would happen. His purpose was strategic: to show up at the meeting with something so substantive that everyone else would have to fall into the role of simply proposing modifications to it, so that the overall shape, and therefore schedule, of the project would be roughly as he wanted.
Dans sa biographie en plusieurs volumes de Thomas Jefferson, « Jefferson et son temps », Dumas Malone raconte comment Jefferson a dirigé la première réunion tenue pour décider de l'organisation de la future Université de Virginie. L'université était au départ une idée de Jefferson, mais (comme c'est le cas partout, pas uniquement dans les projets libres) beaucoup d'autres personnes se sont jointes au projet rapidement, chacun avec ses propres intérêts et son propre agenda. Lorsqu'ils se sont réunis la première fois pour débroussailler le terrain, Jefferson s'est présenté avec des plans architecturaux méticuleusement préparés, un budget détaillé pour la construction et le fonctionnement, une proposition de cursus et les noms de professeurs qu'il voulait faire venir d'Europe. Personne d'autre dans l'assemblée n'était de loin aussi bien préparé, le groupe a donc dû s'en remettre à la vision de Jefferson et finalement l'université a été créée pratiquement selon ses plans. Le fait que le coût de la construction ait largement dépassé le budget et que beaucoup de ses idées n'aient finalement pas fonctionnées (pour diverses raisons), étaient certainement prévus par Jefferson. Son but était stratégique : se présenter devant l'assemblée avec quelque chose de si solide que tous les autres devraient se limiter au rôle de consultant et de proposer de simples modifications. Il s'assurait aussi que le projet se déroule comme il le souhaitait dans les grandes lignes et le planning qu'il avait imaginé.
In the case of a free software project, there is no single "meeting", but instead a series of small proposals made mostly by means of the issue tracker. But if you have some credibility in the project to start with, and you start assigning various features, enhancements, and bugs to target releases in the issue tracker, according to some announced overall plan, people will mostly go along with you. Once you've got things laid out more or less as you want them, the conversations about actual release dates will go much more smoothly.
En ce qui concerne les logiciels libres, il n'y a pas de réunion unique, mais plutôt une série de petites propositions faites principalement par le biais du référentiel de bogues. Mais si vous avez déjà une certaine crédibilité au sein du projet et que vous commencez à assigner différentes fonctionnalités, améliorations et bogues à des versions précises, en accord avec un plan général annoncé, les gens vous suivront sans problème. Une fois que vous avez établi les choses à peu près comme vous le désirez, les conversations à propos de la date de sortie se feront beaucoup plus facilement.
It is crucial, of course, to never present any individual decision as written in stone. In the comments associated with each assignment of an issue to a specific future release, invite discussion, dissent, and be genuinely willing to be persuaded whenever possible. Never exercise control merely for the sake of exercising control: the more deeply others participate in the release planning process (see the section called “Share Management Tasks as Well as Technical Tasks” in Chapter 8, Managing Volunteers), the easier it will be to persuade them to share your priorities on the issues that really count for you.
Il est bien sûr crucial de ne jamais présenter une décision individuelle comme définitive. Dans les commentaires associés à chaque attribution d'un problème à une version particulière invitez à la discussion, à la protestation et montrez vous authentiquement ouvert à la persuasion dès que c'est possible. Ne dirigez pas simplement pour le plaisir de diriger : plus les autres personnes participent au planning de sortie (voir la section « Partager les tâches de gestion aussi bien que les tâches techniques » du Chapitre 8, « Gérer les volontaires »), plus il sera facile pour vous de les convaincre du bien-fondé de vos priorités sur les points qui vous tiennent à cœur.
The other way the project can lower tensions around release planning is to make releases fairly often. When there's a long time between releases, the importance of any individual release is magnified in everyone's minds; people are that much more crushed when their code doesn't make it in, because they know how long it might be until the next chance. Depending on the complexity of the release process and the nature of your project, somewhere between every three and six months is usually about the right gap between releases, though maintenance lines may put out micro releases a bit faster, if there is demand for them.
Le projet peut aussi réduire les tensions autour du planning en proposant de nouvelles versions relativement souvent. Quand beaucoup de temps s'écoule entre les sorties, l'importance d'une nouvelle version est décuplée dans l'esprit des gens et ils sont beaucoup plus affectés si leur code n'y est pas incorporé parce qu'ils savent qu'ils va leur falloir attendre longtemps avant qu'ils n'aient une nouvelle chance. Selon la complexité du processus de publication et la nature de votre projet, un délai de trois à six mois est en général un bon écart entre deux sorties bien que les lignes de maintenance puissent soutenir un rythme plus important pour les micro-versions si elles sont nécessaires.
