POSS Chap 7 Part 5
Un article de Framalang Wiki.
[modifier] Testing and Releasing / Tests et publication
Once the source tarball is produced from the stabilized release branch, the public part of the release process begins. But before the tarball is made available to the world at large, it should be tested and approved by some minimum number of developers, usually three or more. Approval is not simply a matter of inspecting the release for obvious flaws; ideally, the developers download the tarball, build and install it onto a clean system, run the regression test suite (see the section called “Automated testing”) in Chapter 8, Managing Volunteers, and do some manual testing. Assuming it passes these checks, as well as any other release checklist criteria the project may have, the developers then digitally sign the tarball using GnuPG (http://www.gnupg.org/), PGP (http://www.pgpi.org/), or some other program capable of producing PGP-compatible signatures.
Une fois le tarball de sources créé à partir de branche de publication stabilisée, la partie visible de la publication commence. Mais avant que le tarball soit mis à la disposition du monde entier, il doit être testé et approuvé par un minimum de développeurs, en général trois ou plus. Cette approbation ne sert pas seulement à chercher des bogues évidents : idéalement, les développeurs téléchargent l'archive, la construisent et l'installent sur un système propre puis effectuent l'ensemble des tests de non-régression (voir la section appelée « Tests automatisés » dans le Chapitre 8, Encadrer les volontaires) et quelques tests manuels. En supposant que l'archive passe ces épreuves, ainsi que toute autre série de critères que le projet pourrait avoir fixés, les développeurs signent numériquement l'archive en utilisant GnuPG (http://www.gnupg.org/), PGP (http://www.pgpi.org/), ou tout autre programme capable de produire une signature compatible PGP.
In most projects, the developers just use their personal digital signatures, instead of a shared project key, and as many developers as want to may sign (i.e., there is a minimum number, but not a maximum). The more developers sign, the more testing the release undergoes, and also the greater the likelihood that a security-conscious user can find a digital trust path from herself to the tarball.
Dans la plupart des projets, les développeurs utilisent leur propre signature numérique plutôt qu'une clé partagé par le projet. Tous les développeurs qui le souhaitent peuvent apposer leur signature (il y en a donc un nombre minimum, mais pas maximum). Un grand nombre de signatures prouve que le programme a fait l'objet de nombreux tests, ce qui accroît la confiance des utilisateurs avertis dans le tarball.
Once approved, the release (that is, all tarballs, zip files, and whatever other formats are being distributed) should be placed into the project's download area, accompanied by the digital signatures, and by MD5/SHA1 checksums (see http://en.wikipedia.org/wiki/Cryptographic_hash_function). There are various standards for doing this. One way is to accompany each released package with a file giving the corresponding digital signatures, and another file giving the checksum. For example, if one of the released packages is scanley-2.5.0.tar.gz, place in the same directory a file scanley-2.5.0.tar.gz.asc containing the digital signature for that tarball, another file scanley-2.5.0.tar.gz.md5 containing its MD5 checksum, and optionally another, scanley-2.5.0.tar.gz.sha1, containing the SHA1 checksum. A different way to provide checking is to collect all the signatures for all the released packages into a single file, scanley-2.5.0.sigs; the same may be done with the checksums.
Une fois approuvés, tous les fichiers (c'est à dire, les tarballs, les fichiers zip et autres formats de paquet) devraient être placés dans la section téléchargement du projet, accompagnés d'une signature numérique et d'une empreinte MD5/SHA1 (voir http://fr.wikipedia.org/wiki/Fonction_de_hachage). Plusieurs standards existent. Une solution consiste à mettre à disposition à coté du paquet le fichier de signature numérique correspondante et le fichier d'empreinte. Par exemple, pour le paquet « scanley-2.5.0.tar.gz », placez dans le même répertoire un fichier « scanley-2.5.0.tar.gz.asc » contenant la signature numérique de l'archive, un fichier « scanley-2.5.0.tar.gz.md5 » contenant l'empreinte MD5 et optionnellement un fichier « scanley-2.5.0.tar.gz.sha1 » contenant l'empreinte SHA1. Il est également possible de rassembler toutes les signatures pour tous les paquets proposés dans un fichier unique, « scanley-2.5.0.sigs », et de faire de même avec les empreintes.
It doesn't really matter which way you do it. Just keep to a simple scheme, describe it clearly, and be consistent from release to release. The purpose of all this signing and checksumming is to give users a way to verify that the copy they receive has not been maliciously tampered with. Users are about to run this code on their computers—if the code has been tampered with, an attacker could suddenly have a back door to all their data. See the section called “Security Releases” later in this chapter for more about paranoia.
Peu importe la solution que vous retiendrez : gardez le système simple, documenté et cohérent entre les publications. Le but de toutes ces signatures et empreintes est de permettre aux utilisateurs de vérifier que la copie qu'ils reçoivent n'a pas été falsifiée à des fins malveillantes. Les utilisateurs s'apprêtent à faire tourner ce code sur leur ordinateur, s'il a été altéré, une personne mal intentionnée pourrait ainsi créer une porte dérobée pour accéder à toutes leurs données. Voir la section « Les mises à jour de sécurité » plus loin dans ce chapitre pour en savoir plus sur la paranoïa.
[modifier] Candidate Releases / Versions candidates
For important releases containing many changes, many projects prefer to put out release candidates first, e.g., scanley-2.5.0-beta1 before scanley-2.5.0. The purpose of a candidate is to subject the code to wide testing before blessing it as an official release. If problems are found, they are fixed on the release branch and a new candidate release is rolled out (scanley-2.5.0-beta2). The cycle continues until no unacceptable bugs are left, at which point the last candidate release becomes the official release—that is, the only difference between the last candidate release and the real release is the removal of the qualifier from the version number.
Pour les versions contenant beaucoup de changements, de nombreux projets publient une version candidate (Release Candidate ou RC), par exemple « scanley-2.5.0-beta1 » avant « scanley-2.5.0 ». Le but d'une version candidate est de soumettre le code à un maximum de testeurs avant de le labelliser version officielle. Si des problèmes apparaissent, ils sont corrigés dans la branche de publication et une nouvelle version candidate est proposée (« scanley-2.5.0-beta2 »). Le cycle se poursuit jusqu'à ce qu'il n'y ait plus de bogues bloquants. La version candidate devient alors la version officielle. L'unique différence entre la dernière version candidate et la version officielle est donc le qualificatif qui est retiré du numéro de la version.
In most other respects, a candidate release should be treated the same as a real release. The alpha, beta, or rc qualifier is enough to warn conservative users to wait until the real release, and of course the announcement e-mails for the candidate releases should point out that their purpose is to solicit feedback. Other than that, give candidate releases the same amount of care as regular releases. After all, you want people to use the candidates, because exposure is the best way to uncover bugs, and also because you never know which candidate release will end up becoming the official release.
Pour le reste, une version candidate doit être traitée comme une version finale. Les qualificatifs « alpha », « beta » ou « rc » suffisent à avertir les utilisateurs conservateurs de patienter jusqu'à la publication finale et les e-mails d'annonce de la version candidate doivent mettre en avant que son rôle est d'obtenir des retours de la part des utilisateurs. Ces précautions à part, accordez aux versions candidates la même attention qu'aux versions officielles car leur mise à disposition est la meilleure façon de trouver de nouveaux bogues et parce que -après tout- vous ne savez jamais quelle version candidate deviendra la version officielle.
[modifier] Announcing Releases / Annoncer une publication
Announcing a release is like announcing any other event, and should use the procedures described in the section called “Publicity” in Chapter 6, Communications. There are a few specific things to do for releases, though.
Annoncer une publication est comme annoncer n'importe quel autre événement et les procédures décrites dans la section « Les annonces » dans le Chapitre 6, Communication s'appliquent. Il y a cependant quelques points particuliers à prendre en compte dans cette situation.
Whenever you give the URL to the downloadable release tarball, make sure to also give the MD5/SHA1 checksums and pointers to the digital signatures file. Since the announcement happens in multiple forums (mailing list, news page, etc.), this means users can get the checksums from multiple sources, which gives the most security-conscious among them extra assurance that the checksums themselves have not been tampered with. Giving the link to the digital signature files multiple times doesn't make those signatures more secure, but it does reassure people (especially those who don't follow the project closely) that the project takes security seriously.
A chaque fois que vous fournissez l'URL d'un tarball, assurez vous de fournir également les empreintes MD5/SHA1 et des liens vers les fichiers contenant les signatures numériques. Puisque l'annonce se fera sur plusieurs medias (listes de diffusion, pages d'informations, etc.), les utilisateurs peuvent obtenir les empreintes depuis différentes sources, ce qui donne aux utilisateurs les plus exigeants sur la sécurité l'assurance complémentaire que ces dernières n'ont pas été altérées. Proposer différents liens vers les fichiers de signatures numériques ne rend pas ces signatures plus sures, mais démontre aux gens (en particulier ceux qui ne suivent pas le projet de près) que la sécurité est prise au sérieux.
In the announcement e-mail, and on news pages that contain more than just a blurb about the release, make sure to include the relevant portion of the CHANGES file, so people can see why it might be in their interests to upgrade. This is as important with candidate releases as with final releases; the presence of bugfixes and new features is important in tempting people to try out a candidate release.
Dans l'e-mail d'annonce et dans les pages d'information contenant plus qu'un simple argumentaire « commercial » assurez vous d'inclure les passages pertinents du fichier CHANGES pour informer les utilisateurs de que cette mise à jour leur apporterait. Cela vaut tant pour les versions candidates que pour les versions finales, la présence de correctifs de bogues et de nouvelles fonctionnalités est importante pour pousser les gens à testent les versions candidates.
Finally, don't forget to thank the development team, the testers, and all the people who took the time to file good bug reports. Don't single out anyone by name, though, unless there's someone who is individually responsible for a huge piece of work, the value of which is widely recognized by everyone in the project. Just be wary of sliding down the slippery slope of credit inflation (see the section called “Credit” in Chapter 8, Managing Volunteers).
Pour finir, n'oubliez pas de remercier l'équipe de développement, les testeurs et toutes les personnes qui ont pris le temps de faire de bons rapports de bogues. Ne citez personne en particulier, sauf quelqu'un individuellement à l'origine d'un travail particulièrement important, un travail que tout le monde a pu apprécier au sein du projet. Ne vous laissez entraîner sur la pente glissante de la surenchère de remerciements (voir la section « Remerciements » dans le Chapitre 8, Gérer les volontaires).
