- Move includes.nav*.sgml to share/sgml/navibar.ent and
<lang>/share/sgml/navibar.l10n.ent.
- Move includes.sgml and includes.xsl to
share/sgml/common.ent, share/sgml/header.ent, <lang>/share/sgml/l10n.ent,
and <lang>/share/sgml/header.l10n.ent.
- Move most of XSLT libraries to share/sgml/*.xsl and
<lang>/share/sgml/*.xsl.
- Move news.xml and other *.xml files for the similar purpose
to share/sgml/*.xml and <lang>/share/sgml/*.xml.
- Switch to use a custom DTD for HTML document. Now we use
"-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension", which is
HTML 4.01 + some entities previously pulled via
"<!ENTITY % includes SYSTEM "includes.sgml"> %includes;" line.
The location of entity file will be resolved by using catalog file.
- Add DOCTYPE declearation to XML documents. This makes the followings
possible:
* Use of &foo; entities for SGML in an XML file instead of defining
{$foo} as the same content.
* &symbolic; entities for Latin characters.
- Duplicated information between SGML and XML, or English and
translated doc, has been removed as much as possible.
77 lines
4.1 KiB
Text
77 lines
4.1 KiB
Text
<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
|
|
<!ENTITY base CDATA "..">
|
|
<!ENTITY date "$FreeBSD: www/fr/releng/charter.sgml,v 1.4 2005/10/06 12:56:08 blackend Exp $">
|
|
<!ENTITY title "Charte pour l'équipe en charge des nouvelles versions">
|
|
<!ENTITY % navinclude.developers "INCLUDE">
|
|
]>
|
|
|
|
<!--
|
|
The FreeBSD French Documentation Project
|
|
Original revision: 1.1
|
|
|
|
Version francaise : Stephane Legrand <stephane@freebsd-fr.org>
|
|
-->
|
|
|
|
<html>
|
|
&header;
|
|
|
|
<p>L'équipe en charge des nouvelles versions a les responsabilités suivantes
|
|
:</p>
|
|
|
|
<ul>
|
|
<li><p>Mettre en place et publier le planning des versions officielles
|
|
du projet FreeBSD.</p></li>
|
|
|
|
<li><p>Documenter et formaliser les procédures de création des versions de manière à ce que
|
|
le processus soit constamment examiné et amélioré. Cela inclu
|
|
davantage de documentation à propos du cluster dédié aux ports et à propos des procédures
|
|
d'organisation des paquetages.</p></li>
|
|
|
|
<li><p>Mettre en place et publier les dates de "gel" du code source et jouer le rôle de
|
|
comité chargé de décider quels changements peuvent éventuellement être faits
|
|
durant ces laps de temps. Cela inclue les "gels" pour "HEAD" lors de la
|
|
préparation d'une version en .0 ainsi que les traditionnels
|
|
"gels" <tt>RELENG_*</tt> lors de la préparation d'une version -STABLE.</p></li>
|
|
|
|
<li><p>Création et maintenance des branches <tt>RELENG_*</tt> de l'arbre
|
|
<tt>src/</tt>. Cela inclu la prise de décision finale sur les changements
|
|
qui sont effectués (et qui resteront) dans la branche -STABLE avant la
|
|
mise en place de la nouvelle branche.</p></li>
|
|
|
|
<li><p>Travailler en coopération avec l'équipe principale et/ou la Fondation FreeBSD pour codifier un
|
|
ensemble de règles que les revendeurs doivent respecter pour être autorisés
|
|
à appeler un produit "FreeBSD" ou "Version officielle
|
|
FreeBSD".</p></li>
|
|
|
|
<li><p>Tester et intégrer les paquetages requis à partir de la collection
|
|
des ports sur le support (CD-Rom, ...) officiel choisi. Portmgr@ est
|
|
responsable de la gestion du "gel" des <tt>ports/</tt> et
|
|
fourni l'ensemble des paquetages à partir des ports pouvant être redistribués.
|
|
re@ est également responsable de la répartition de ces paquetages sur les
|
|
différents ISOs en tenant compte des contraintes du support choisi. re@ est
|
|
l'ultime responsable pour veiller à ce que tous les paquetages
|
|
nécessaires soient disponibles sur le support choisi mais la coopération
|
|
de portmgr@ est essentiel.</p></li>
|
|
|
|
<li><p>Coordination avec le Projet de Documentation FreeBSD pour
|
|
s'assurer qu'un ensemble cohérent de documentations est fourni avec
|
|
la nouvelle version. Cela inclu la possibilité de demander qu'aucune
|
|
modification importante ne soit faite dans les documentations durant
|
|
les semaines qui précèdent la sortie d'une version.</p></li>
|
|
|
|
<li><p>Coordination avec l'équipe de l'officier de sécurité afin de s'assurer que
|
|
les versions FreeBSD en cours de création ne sont pas affectées par des failles de
|
|
sécurité récemment découvertes. De plus, approximativement une semaine après la sortie d'une version,
|
|
la responsabilité de l'approbation des modifications sur la branche <tt>RELENG_X_Y</tt>
|
|
est transférée de l'équipe en charge des versions à l'équipe en charge de la
|
|
sécurité. La date exacte du transfert est choisie en commun accord entre les
|
|
deux parties une fois qu'il est clair que la nouvelle version est un succès. Une annonce
|
|
est alors envoyée sur la liste developers@.</p></li>
|
|
|
|
<li><p>Envoyer des messages sur announce@FreeBSD.org au nom du
|
|
projet pour annoncer les nouvelles versions de FreeBSD.</p></li>
|
|
</ul>
|
|
|
|
&footer;
|
|
</body>
|
|
</html>
|