POSS Chap 7 Part 4

De Framalang Wiki.

Version du 17 novembre 2008 à 06:54 par Olivier (Discuter | contributions)

(diff) ← Version précédente | Voir la version courante (diff) | Version suivante → (diff)

Sommaire

Packaging / La création de paquets

The canonical form for distribution of free software is as source code. This is true regardless of whether the software normally runs in source form (i.e., can be interpreted, like Perl, Python, PHP, etc.) or needs to be compiled first (like C, C++, Java, etc.). With compiled software, most users will probably not compile the sources themselves, but will instead install from pre-built binary packages (see the section called “Binary Packages” later in this chapter). However, those binary packages are still derived from a master source distribution. The point of the source package is to unambiguously define the release. When the project distributes « Scanley 2.5.0 », what it means, specifically, is « The tree of source code files that, when compiled (if necessary) and installed, produces Scanley 2.5.0."
les logiciels libres sont traditionnellement distribués sous la forme de code source, qu'il soit interprété (Perl, Python, PHP, etc.) ou qu'il ait besoin d'être compilés au préalable (C, C++, Java, etc.). Les logiciels compilés ne seront généralement pas construits par les utilisateurs eux-mêmes mais installés sous la forme d'un paquet binaire prêts à l'exécution (voir la section appelée « Paquets binaires » plus loin dans ce chapitre). Ces paquets sont néanmoins toujours issus d'une source de distribution de référence. Le paquet source doit porter un identifiant de version sans ambiguïté possible. Un paquet nommé « Scanley 2.5.0 » signifie en fait « l'arborescence de fichiers sources constituants Scanley 2.5.0 une fois compilée (si nécessaire) et installée ».
There is a fairly strict standard for how source releases should look. One will occasionally see deviations from this standard, but they are the exception, not the rule. Unless there is a compelling reason to do otherwise, your project should follow this standard too.
Cette arborescence répond à des normes plutôt strictes. On en trouvera occasionnellement des écarts, mais cela reste exceptionnel. En dehors de raisons impératives d'y déroger, votre projet devrait lui aussi suivre ces normes.

Format / Le format

The source code should be shipped in the standard formats for transporting directory trees. For Unix and Unix-like operating systems, the convention is to use TAR format, compressed by compress, gzip, bzip or bzip2. For MS Windows, the standard method for distributing directory trees is zip format, which happens to do compression as well, so there is no need to compress the archive after creating it.
Le code source devrait être mis à disposition dans le format standard du transport d'arborescences de répertoires. Pour les systèmes d'exploitation Unix ou dérivés, la convention est le format TAR, compressé par compress, gzip, bzip ou bzip2. Pour MS Windows, c'est le format zip. Ce dernier assure également la compression, ce qui élimine le besoin de compresser l'archive après sa création.

TAR Files

TAR stands for « Tape ARchive », because tar format represents a directory tree as a linear data stream, which makes it ideal for saving directory trees to tape. The same property also makes it the standard for distributing directory trees as a single file. Producing compressed tar files (or tarballs) is pretty easy. On some systems, the tar command can produce a compressed archive itself; on others, a separate compression program is used.

Les fichiers TAR

TAR signifie « Tape ARchive », car le format tar représente une arborescence de répertoires comme un flux linéaire de données, ce qui le rend idéal pour sauvegarder des répertoires sur cassette. Cette même propriété en fait le standard pour distribuer les arborescences sous la forme d'un fichier unique. La création de fichiers tar compressés (ou tarballs) est plutôt aisée. Sur certains systèmes, la commande tar peut produire elle-même des archives compressés alors que sur d'autres, un programme de compression distinct est employé.

Name and Layout / Nom et structure

The name of the package should consist of the software's name plus the release number, plus the format suffixes appropriate for the archive type. For example, Scanley 2.5.0, packaged for Unix using GNU Zip (gzip) compression, would look like this:

scanley-2.5.0.tar.gz

or for Windows using zip compression:

scanley-2.5.0.zip

Le nom du paquet est composé du nom du logiciel suivi du numéro de version et du suffixe du format correspondant au type d'archive. Par exemple, le nom pour Scanley 2.5.0, pour Unix, compressé avec GNU Zip (gzip) ressemble à ceci :

scanley-2.5.0.tar.gz

ou pour Windows, en utilisant une compression de type zip :

scanley-2.5.0.zip
Either of these archives, when unpacked, should create a single new directory tree named scanley-2.5.0 in the current directory. Underneath the new directory, the source code should be arranged in a layout ready for compilation (if compilation is needed) and installation. In the top level of new directory tree, there should be a plain text README file explaining what the software does and what release this is, and giving pointers to other resources, such as the project's web site, other files of interest, etc. Among those other files should be an INSTALL file, sibling to the README file, giving instructions on how to build and install the software for all the operating systems it supports. As mentioned in the section called “How to Apply a License to Your Software” in Chapter 2, Getting Started, there should also be a COPYING or LICENSE file, giving the software's terms of distribution.
Ces deux archives, une fois décompressées, créent un nouveau dossier nommé scanley-2.5.0 dans le dossier courant. Dans ce nouveau dossier, le code source est prêt à être compilé (si une compilation est requise) et à être installé. Se trouve à la racine du nouveau dossier on un fichier texte nommé README (ou LISEZ-MOI) expliquant le but du logiciel et sa version accompagné d'autres ressources comme le site web du projet, d'autres fichiers pertinents, etc. Parmi ces autres fichiers, on trouve un fichier INSTALL, semblable au fichier README, qui fournit les instructions permettant de construire et d'installer le logiciel pour tous les systèmes d'exploitation supportés. Comme nous l'avons déjà évoqué dans la section « Comment appliquer une licence à votre logiciel » dans le Chapitre 2, « Démarrer », on trouve également un fichier COPYING ou LICENCE, précisant les conditions de distribution du logiciel.

There should also be a CHANGES file (sometimes called NEWS), explaining what's new in this release. The CHANGES file accumulates changelists for all releases, in reverse chronological order, so that the list for this release appears at the top of the file. Completing that list is usually the last thing done on a stabilizing release branch; some projects write the list piecemeal as they're developing, others prefer to save it all up for the end and have one person write it, getting information by combing the version control logs. The list looks something like this:

Version 2.5.0 (20 December 2004, from /branches/2.5.x) http://svn.scanley.org/repos/svn/tags/2.5.0/

New features, enhancements:
   * Added regular expression queries (issue #53)
   * Added support for UTF-8 and UTF-16 documents
   * Documentation translated into Polish, Russian, Malagasy
   * ...
Bugfixes:
   * fixed reindexing bug (issue #945)
   * fixed some query bugs (issues #815, #1007, #1008)
   * ...

On doit également y trouver un fichier CHANGES ou MODIFICATIONS (parfois appelé NEWS ou NOUVEAUTES) reprenant les nouveautés apportées par cette version. Le fichier CHANGES liste les modifications portant sur toutes les versions, dans l'ordre chronologique inversé, afin que les modifications de la version courante apparaissent en premier. Compléter cette liste est en général la dernière chose devant être effectuée sur une branche de publication en cours de stabilisation. Certains projets rédigent cette liste au fur et à mesure du développement, d'autres préfèrent conserver cette étape pour la fin et charger une personne de sa rédaction. Les modifications sont tirées des journaux de gestion de version et ressemblent à cet extrait :

Version 2.5.0 (20 décembre 2004, depuis /branches/2.5.x) http://svn.scanley.org/repos/svn/tags/2.5.0/

Nouvelles fonctionnalités, améliorations
  * Ajout des requêtes d'expressions régulières
  * Ajout du support UTF-8 et UTF-16 pour les documents
  * Documentation traduite en polonais, russe et malgache
  * ...
Correctifs :
* Correction du bogue de ré-indexation (Bogue #945)
* Correction de quelques bogues de requêtes (Bogues #815, #1007, #1008)
The list can be as long as necessary, but don't bother to include every little bugfix and feature enhancement. Its purpose is simply to give users an overview of what they would gain by upgrading to the new release. In fact, the changelist is customarily included in the announcement email (see the section called “Testing and Releasing” later in this chapter), so write it with that audience in mind.
La liste peut être aussi longue que nécessaire, mais il n'est pas indispensable d'y inclure chaque petite correction ou amélioration. Elle sert à fournir aux utilisateurs un panorama de ce qu'ils gagneront à utiliser la nouvelle version. En fait, la liste des modifications est habituellement inclue dans l'e-mail d'annonce (voir la section appelée « Tests et sortie » plus loin dans ce chapitre), rédigez-la donc en gardant en tête sa future audience.

CHANGES Versus ChangeLog

Traditionally, a file named ChangeLog lists every change ever made to a project—that is, every revision committed to the version control system. There are various formats for ChangeLog files; the details of the formats aren't important here, as they all contain the same information: the date of the change, its author, and a brief summary (or just the log message for that change).

A CHANGES file is different. It too is a list of changes, but only the ones thought important for a certain audience to see, and often with metadata like the exact date and author stripped off. To avoid confusion, don't use the terms interchangeably. Some projects use « NEWS » instead of « CHANGES »; although this avoids the potential for confusion with « ChangeLog », it is a bit of a misnomer, since the CHANGES file retains change information for all releases, and thus has a lot of old news in addition to the new news at the top.

CHANGES et ChangeLog Traditionnellement, un fichier nommé ChangeLog liste l'intégralité des changements apportés à un projet, c'est à dire chaque révision du logiciel de gestion de version. Il existe différents formats pour les fichiers ChangeLog, les détails du format ne sont pas importants ici puisqu'ils contiennent tous les mêmes informations : la date de la modification, son auteur ainsi qu'un bref résumé (ou simplement le message de journal pour ce changement).

Un fichier CHANGES est différent. Il ne reprend que les modifications jugées importantes pour un certain public et certaines méta-données comme la date exacte ou l'auteur ont été supprimées. Pour éviter les confusions n'interchangez pas ces deux termes. Certains projets utilisent « NEWS » plutôt que « CHANGES ». Bien que cela évite la confusion potentielle avec « ChangeLog », le terme est mal choisi puisque le fichier CHANGES conserve les modifications portant sur toutes les versions antérieures et comprend donc beaucoup d'anciennes « nouveautés » en plus de celles figurant en haut du fichier.
ChangeLog files may be slowly disappearing anyway. They were helpful in the days when CVS was the only choice of version control system, because change data was not easy to extract from CVS. However, with more recent version control systems, the data that used to be kept in the ChangeLog can be requested from the version control repository at any time, making it pointless for the project to keep a static file containing that data—in fact, worse than pointless, since the ChangeLog would merely duplicate the log messages already stored in the repository.
Les fichiers ChangeLog semblent de toute façon disparaître peu à peu. Ils étaient utiles à l'époque où CVS était le logiciel de gestion de version unique et dont les données n'étaient pas simples à extraire. Les logiciels de gestion de version plus récents peuvent facilement restituer par requêtes les données qui étaient jadis inscrites dans le ChangeLog, ce qui rend la maintenance d'un fichier statique contenant ces données inutile, voire dangereux puisque le ChangeLog se résume alors à une réplique du journal de messages déjà enregistrés dans le dépôt.
The actual layout of the source code inside the tree should be the same as, or as similar as possible to, the source code layout one would get by checking out the project directly from its version control repository. Usually there are a few differences, for example because the package contains some generated files needed for configuration and compilation (see the section called « Compilation and Installation » later in this chapter), or because it includes third-party software that is not maintained by the project, but that is required and that users are not likely to already have. But even if the distributed tree corresponds exactly to some development tree in the version control repository, the distribution itself should not be a working copy (see working copy). The release is supposed to represent a static reference point—a particular, unchangeable configuration of source files. If it were a working copy, the danger would be that the user might update it, and afterward think that he still has the release when in fact he has something different.
La structure du code source à l'intérieur de l'arborescence doit être aussi proche que possible de celle du projet tel qu'il se trouve dans le dépôt de gestion de version. On trouve en général quelques différences, par exemple si le paquet contient certains fichiers générés requis pour la configuration et la compilation (voir la section nommée « Compilation et Installation » plus loin dans ce chapitre) ou parce qu'il contient un programme tiers qui n'est pas maintenu par le projet mais qui est nécessaire et que les utilisateurs ne possèdent probablement pas encore. Mais même si l'arborescence distribuée correspond exactement à une arborescence de développement dans le dépôt de gestion de version, la distribution elle-même ne doit pas être une copie de travail (voir « Copie de travail » dans la section « Gestion de version » du chapitre 3 «Infrastructure technique ») mais doit représenter un point de référence immuable, une configuration particulière et non-modifiable de fichiers source. Une copie de travail pourrait être modifiée par l'utilisateur qui penserait alors disposer de la version officielle alors qu'il s'agirait d'une version modifiée.

Remember that the package is the same regardless of the packaging. The release—that is, the precise entity referred to when someone says « Scanley 2.5.0"—is the tree created by unpacking a zip file or tarball. So the project might offer all of these for download:

scanley-2.5.0.tar.bz2 scanley-2.5.0.tar.gz

scanley-2.5.0.zip

Souvenez vous que le contenu est toujours le même, indépendamment du paquet. La version, c'est à dire l'entité précise à laquelle on fait référence quand on parle de « Scanley 2.5.0 », est l'arborescence créé lorsqu'on extrait les fichiers d'une archive zip ou tarball. Le projet devrait donc proposer tous ces fichiers au téléchargement :

scanley-2.5.0.tar.bz2 scanley-2.5.0.tar.gz

scanley-2.5.0.zip
...but the source tree created by unpacking them must be the same. That source tree is the distribution; the form in which it is downloaded is merely a matter of convenience. Certain trivial differences between source packages are allowable: for example, in the Windows package, text files should have lines ending with CRLF (Carriage Return and Line Feed), while Unix packages should use just LF. The trees may be arranged slightly differently between source packages destined for different operating systems, too, if those operating systems require different sorts of layouts for compilation. However, these are all basically trivial transformations. The basic source files should be the same across all the packagings of a given release.
... mais l'arborescence issue de leur extraction doit rester identique. Cette arborescence source est la distribution ; la forme sous laquelle elle est téléchargée est une simple question de commodité. Certaines différences triviales entre les paquets sources sont possibles : par exemple les fichiers textes de paquets Windows les lignes devraient se terminer par CRLF (Carriage Return and Line Feed [NdT : retour du chariot et passage à la ligne] tandis que les paquets Unix ne devraient utiliser que LF. Les arborescences peuvent être arrangées légèrement en fonction du système d'exploitation cible si ce dernier demande une structure spécifique pour la compilation. Il s'agit néanmoins de transformations triviales. Les fichiers sources de base devraient être identiques entre tous les paquets pour une version particulière.
To capitalize or not to capitalize / De l'utilisation des majuscules
When referring to a project by name, people generally capitalize it as a proper noun, and capitalize acronyms if there are any: « MySQL 5.0 », « Scanley 2.5.0 », etc. Whether this capitalization is reproduced in the package name is up to the project. Either Scanley-2.5.0.tar.gz or scanley-2.5.0.tar.gz would be fine, for example (I personally prefer the latter, because I don't like to make people hit the shift key, but plenty of projects ship capitalized packages). The important thing is that the directory created by unpacking the tarball use the same capitalization. There should be no surprises: the user must be able to predict with perfect accuracy the name of the directory that will be created when she unpacks a distribution.
Les gens utilisent naturellement des majuscules dans les noms de projets, alors traités comme des noms propres. Il en est de même pour les acronymes : « MySQL 5.0 », « Scanley 2.5.0 », etc. C'est au projet de décider si le nom du paquet doit utiliser la même casse. « Scanley-2.5.0.tar.gz » ou « scanley-2.5.0.tar.gz » sont tous les deux valables par exemple (je préfère la dernière proposition pour ne pas forcer les gens à appuyer sur MAJ, mais de nombreux projets utilisent une majuscule dans le nom du paquet). Il faut néanmoins que le répertoire créé en extrayant le tarball utilise la même convention. Évitez les surprises, l'utilisateur devrait pouvoir prédire sans ambiguïté le nom exact du répertoire créé quand il extraira la distribution.
Pre-releases / Pré-versions

When shipping a pre-release or candidate release, the qualifier is truly a part of the release number, so include it in the name of the package's name. For example, the ordered sequence of alpha and beta releases given earlier in the section called « Release Number Components » would result in package names like this:

scanley-2.3.0-alpha1.tar.gz scanley-2.3.0-alpha2.tar.gz scanley-2.3.0-beta1.tar.gz scanley-2.3.0-beta2.tar.gz scanley-2.3.0-beta3.tar.gz scanley-2.3.0.tar.gz

The first would unpack into a directory named scanley-2.3.0-alpha1, the second into scanley-2.3.0-alpha2, and so on.

Quand vous rendez publique une pré-version ou une version candidate, le qualificatif fait effectivement partie du numéro de version, par conséquent ajoutez le au nom du paquet. Par exemple, les phases successives alpha et beta déjà abordées dans la section « Les composants d'un numéro de version » correspondraient aux noms de paquets suivants :

scanley-2.3.0-alpha1.tar.gz scanley-2.3.0-alpha2.tar.gz scanley-2.3.0-beta1.tar.gz scanley-2.3.0-beta2.tar.gz scanley-2.3.0-beta3.tar.gz scanley-2.3.0.tar.gz

Le premier paquet est extrait dans un répertoire nommé « scanley-2.3.0-alpha1 », le second dans un répertoire « scanley-2.3.0-alpha2 » et ainsi de suite.

Compilation and Installation / Compilation et installation

For software requiring compilation or installation from source, there are usually standard procedures that experienced users expect to be able to follow. For example, for programs written in C, C++, or certain other compiled languages, the standard under Unix-like systems is for the user to type:

  $ ./configure
  $ make
  # make install

Lorsqu'une compilation ou une installation depuis la source sont nécessaires il existe en général des procédures standardisées que les utilisateurs expérimentés connaissent. Par exemple, pour les programmes écrits en C, C++ ou certains autres langages compilés, la méthode standard sous Unix et dérivés est la suivante :

 $ ./configure
 $ make
 # make install
The first command autodetects as much about the environment as it can and prepares for the build process, the second command builds the software in place (but does not install it), and the last command installs it on the system. The first two commands are done as a regular user, the third as root. For more details about setting up this system, see the excellent GNU Autoconf, Automake, and Libtool book by Vaughan, Elliston, Tromey, and Taylor. It is published as treeware by New Riders, and its content is also freely available online at http://sources.redhat.com/autobook/.
La première commande détecte automatiquement autant que possible sur l'environnement et prépare l'étape de construction, la seconde commande construit le logiciel (mais ne l'installe pas) et la dernière commande l'installe sur le système. Les deux premières sont effectuées en tant qu'utilisateur simple, la troisième en tant qu'administrateur. Pour plus de détails à propos de la mise en place de ce système je vous renvois à l'excellent livre GNU Autoconf, Automake et Libtool par Vaughan, Elliston, Tromey et Taylor. Il est publié en tant que « treeware » par New Riders et son contenu est accessible librement en ligne à l'adresse http://sources.redhat.com/autobook/.
This is not the only standard, though it is one of the most widespread. The Ant (http://ant.apache.org/) build system is gaining popularity, especially with projects written in Java, and it has its own standard procedures for building and installing. Also, certain programming languages, such as Perl and Python, recommend that the same method be used for most programs written in that language (for example, Perl modules use the command perl Makefile.pl). If it's not obvious to you what the applicable standards are for your project, ask an experienced developer; you can safely assume that some standard applies, even if you don't know what it is at first.
Ce n'est pas le seul standard, bien que ce soit le plus répandu. Le système de construction « Ant » (http://ant.apache.org/) gagne en popularité, particulièrement auprès des projets écrits en Java, et possède ses propres procédures standards pour la construction et l'installation. Certains langages de programmation, tels que Perl et Python, recommandent également une méthode standard pour les programmes écrits dans leur langage (par exemple, les modules Perl emploient la commande perl Makefile.pl). Si les standards applicables à votre projet ne vous paraissent pas évidents, demandez à un programmeur expérimenté ; il en existe très probablement un que vous ne le connaissez pas encore.
Whatever the appropriate standards for you project are, don't deviate from them unless you absolutely must. Standard installation procedures are practically spinal reflexes for a lot of system administrators now. If they see familiar invocations documented in your project's INSTALL file, that instantly raises their faith that your project is generally aware of conventions, and that it is likely to have gotten other things right as well. Also, as discussed in the section called “Downloads” in Chapter 2, Getting Started, having a standard build procedure pleases potential developers.
Choisissez le standard plus adapté à votre projet et n'en changez pas sans absolue nécessité. Les procédures d'installation standards sont devenus des réflexes conditionnés pour beaucoup d'administrateurs système. S'ils retrouvent des commandes familières dans le fichier INSTALL de votre projet, leur confiance dans votre connaissance des normes de construction et par extrapolation du projet dans son ensemble sera confortée . De même, comme nous l'avons vu dans la section « Téléchargements » du chapitre 2 « Démarrer », utiliser une séquence de construction standard plaît aux développeurs potentiels.
On Windows, the standards for building and installing are a bit less settled. For projects requiring compilation, the general convention seems to be to ship a tree that can fit into the workspace/project model of the standard Microsoft development environments (Developer Studio, Visual Studio, VS.NET, MSVC++, etc.). Depending on the nature of your software, it may be possible to offer a Unix-like build option on Windows via the Cygwin (http://www.cygwin.com/) environment. And of course, if you're using a language or programming framework that comes with its own build and install conventions—e.g., Perl or Python—you should simply use whatever the standard method is for that framework, whether on Windows, Unix, Mac OS X, or any other operating system.
Sous Windows, les standards de construction et d'installation ne sont pas aussi bien définis. Pour les projets nécessitant un compilation, la convention générale semble être une arborescence pouvant s'intégrer dans l'espace de travail des environnements de développement standards de Microsoft (Developper Studio, Visual Studio, VS.NET, MSVC++, etc.). Selon la nature de votre logiciel, il peut être possible de proposer une option de construction semblable à celle d'Unix sur Windows grâce à l'environnement Cygwin (http://www.cygwin.com/). Et bien sûr, si vous utilisez un langage ou framework qui utilise ses propres conventions comme Perl ou Python, vous devriez simplement employer la méthode standard adéquate indépendamment du système d'exploitation Windows, Unix, Mac OS ou autres.
Be willing to put in a lot of extra effort in order to make your project conform to the relevant build or installation standards. Building and installing is an entry point: it's okay for things to get harder after that, if they absolutely must, but it would be a shame for the user's or developer's very first interaction with the software to require unexpected steps.
Soyez prêt à faire de nombreux efforts supplémentaires pour rendre votre projet conforme aux standards de construction et d'installation. La construction et l'installation sont le point d'entrée : les choses peuvent devenir plus complexes par la suite si absolument nécessaire mais il serait fortement dommageable pour l'image de votre projet que les utilisateurs aient à fournir plus d'efforts que prévu dès ce premier contact avec le logiciel.

Binary Packages / Paquets binaires

Although the formal release is a source code package, most users will install from binary packages, either provided by their operating system's software distribution mechanism, or obtained manually from the project web site or from some third party. Here « binary » doesn't necessarily mean « compiled"; it just means any pre-configured form of the package that allows a user to install it on his computer without going through the usual source-based build and install procedures. On RedHat GNU/Linux, it is the RPM system; on Debian GNU/Linux, it is the APT (.deb) system; on MS Windows, it's usually .MSI files or self-installing .exe files.
Les paquets embarquant le code source constituent le format académique d'une version mais la plupart des utilisateurs installeront un paquet binaire, fournis par le système de distribution de logiciels de leur système d'exploitation ou téléchargés manuellement depuis le site Web du projet ou d'un tiers. « Binaire » ne signifie pas forcément « compilé », cela veut simplement dire que le paquet est pré-configuré de sorte que l'utilisateur puisse l'installer sur son ordinateur sans avoir à passer par les procédures habituelles de construction / installation du fichier source. On trouve sous Redhat GNU/Linux le système RPM, sous Debian GNU/Linux le système APT (.deb), sur MS Windows en général des fichiers .MSI ou des fichiers d'installation automatique .exe.
Whether these binary packages are assembled by people closely associated with the project, or by distant third parties, users are going to treat them as equivalent to the project's official releases, and will file issues in the project's bug tracker based on the behavior of the binary packages. Therefore, it is in the project's interest to provide packagers with clear guidelines, and work closely with them to see to it that what they produce represents the software fairly and accurately.
Que ces paquets binaires soient assemblés par des personnes proches du projets ou par un tiers, les utilisateurs les considereront tous comme officiels et rapporteront dans le système de suivi des bogues les problèmes rencontrés. Il est donc dans l'intérêt du projet de fournir à ceux qui font les paquets des directives claires et de travailler en étroite collaboration avec eux afin de s'assurer que ce qu'ils produisent est correct et fidèle au logiciel.
The main thing packagers need to know is that they should always base their binary packages on an official source release. Sometimes packagers are tempted to pull a later incarnation of the code from the repository, or include selected changes that were committed after the release was made, in order to provide users with certain bug fixes or other improvements. The packager thinks he is doing his users a favor by giving them the more recent code, but actually this practice can cause a great deal of confusion. Projects are prepared to receive reports of bugs found in released versions, and bugs found in recent trunk and major branch code (that is, found by people who deliberately run bleeding edge code). When a bug report comes in from these sources, the responder will often be able to confirm that the bug is known to be present in that snapshot, and perhaps that it has since been fixed and that the user should upgrade or wait for the next release. If it is a previously unknown bug, having the precise release makes it easier to reproduce and easier to categorize in the tracker.
Les assembleurs doivent impérativement baser leurs paquets binaires sur une version code source officielle. Il arrive qu'ils soient tentés d'extraire une version plus évoluée du dépôt ou d'inclure des modifications choisies ajoutées après la sortie officielle afin d'apporter aux utilisateurs certains correctifs de bogues ou d'autres améliorations. La personne réalisant ce paquet pense rendre service aux utilisateurs en leur offrant le code le plus récent mais peut en fait générer une grande confusion. Les projets sont préparés à recevoir des rapports de bogues rencontrés dans les versions publiées ainsi que pour ceux trouvés dans des ajouts récents au tronc ou à des branches principales du code (des bogues trouvés par ceux qui font tourner délibérément le code le plus récent). Quand un rapport de bogue est enregistré pour une version ou une branche précise, l'intervenant devant y répondre sera dans la plupart des cas capable de confirmer la présence du bogue, d'informer de sa correction éventuelle et alors de conseiller à l'utilisateur de mettre son logiciel à jour ou d'attendre la prochaine version. Si ce bogue n'était pas encore répertorié, connaître précisément la version rend sa catégorisation plus simple dans le système de suivi.
Projects are not prepared, however, to receive bug reports based on unspecified intermediate or hybrid versions. Such bugs can be hard to reproduce; also, they may be due to unexpected interactions in isolated changes pulled in from later development, and thereby cause misbehaviors that the project's developers should not have to take the blame for. I have even seen dismayingly large amounts of time wasted because a bug was absent when it should have been present: someone was running a slightly patched up version, based on (but not identical to) an official release, and when the predicted bug did not happen, everyone had to dig around a lot to figure out why.
Mais les projets ne sont pas préparés à recevoir des rapports de bogues basés sur des versions floues ou hybrides. Ce genre de bogues peut être difficile à reproduire et peuvent être dus à des interactions inattendues entre changements isolés extraits d'un développement plus récent. Ils peuvent donc causer des comportements inattendus sans que les développeurs du projet en soient responsables. La perte de temps liée à une telle situation peut être consternante, j'en ai moi-même été témoin : quelqu'un faisait fonctionner une version légèrement corrigée, basée sur la version officielle mais non identique et comme le bogue mentionné ne pouvait être reproduit, toute l'équipe a cherché en vain la raison de ce comportement inexplicable.
Still, there will sometimes be circumstances when a packager insists that modifications to the source release are necessary. Packagers should be encouraged to bring this up with the project's developers and describe their plans. They may get approval, but failing that, they will at least have notified the project of their intentions, so the project can watch out for unusual bug reports. The developers may respond by putting a disclaimer on the project's web site, and may ask that the packager do the same thing in the appropriate place, so that users of that binary package know what they are getting is not exactly the same as what the project officially released. There need be no animosity in such a situation, though unfortunately there often is. It's just that packagers have a slightly different set of goals from developers. The packagers mainly want the best out-of-the-box experience for their users. The developers want that too, of course, but they also need to ensure that they know what versions of the software are out there, so they can receive coherent bug reports and make compatibility guarantees. Sometimes these goals conflict. When they do, it's good to keep in mind that the project has no control over the packagers, and that the bonds of obligation run both ways. It's true that the project is doing the packagers a favor simply by producing the software. But the packagers are also doing the project a favor, by taking on a mostly unglamorous job in order to make the software more widely available, often by orders of magnitude. It's fine to disagree with packagers, but don't flame them; just try to work things out as best you can.
Il y aura toujours des cas où des assembleurs insisteront pour inclure certaines modifications de la version source. Ces derniers doivent être encouragés à prévenir les développeurs du projet de leurs intentions. Ils peuvent recevoir leur approbation, mais si ce n'est pas le cas, les développeurs du projet seront néanmoins avertis en cas de rapport de bogue inattendu. Les développeurs peuvent répondre en publiant une mise en garde sur le site du projet et peuvent demander à la personne faisant le paquet d'en faire de même à un endroit approprié afin que les personnes utilisant ce paquet binaire sachent que ce qu'ils ont entre les mains n'est pas exactement identique à ce que le projet a officiellement publié. Il faut éviter l'animosité dans une telle situation, ceci étant malheureusement difficile. Les assembleurs ont simplement une vision différente de celle des développeurs. Ils cherchent principalement à apporter aux utilisateurs le meilleur du logiciel. C'est aussi le but des développeurs bien entendu, mais ces derniers doivent également s'assurer de connaître la version exacte des paquets utilisés pour rendre les rapports de bogues cohérents et pour assurer la compatibilité de leur travail. Ces objectifs rentrent parfois en conflit et il faut alors se souvenir que le projet n'a aucun contrôle sur les assembleurs et que chacun a des obligations envers l'autre. En effet, le projet produit généreusement le code mais les assembleurs de leur coté effectue un travail souvent ingrat pour rendre le projet largement accessible, quelque fois d'un ordre de grandeur supérieur à ce que le projet aurait espérer seul. Vous pouvez vous trouver en désaccord mais restez courtois pour que tout se passe pour le mieux.
Outils personnels