doc/fr/releng/charter.sgml
Hiroki Sato 5305bb945d www cleanup mega commit:
- 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.
2006-08-19 21:26:51 +00:00

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'&eacute;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'&eacute;quipe en charge des nouvelles versions a les responsabilit&eacute;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&eacute;dures de cr&eacute;ation des versions de mani&egrave;re &agrave; ce que
le processus soit constamment examin&eacute; et am&eacute;lior&eacute;. Cela inclu
davantage de documentation &agrave; propos du cluster d&eacute;di&eacute; aux ports et &agrave; propos des proc&eacute;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&ocirc;le de
comit&eacute; charg&eacute; de d&eacute;cider quels changements peuvent &eacute;ventuellement &ecirc;tre faits
durant ces laps de temps. Cela inclue les "gels" pour "HEAD" lors de la
pr&eacute;paration d'une version en .0 ainsi que les traditionnels
"gels" <tt>RELENG_*</tt> lors de la pr&eacute;paration d'une version -STABLE.</p></li>
<li><p>Cr&eacute;ation et maintenance des branches <tt>RELENG_*</tt> de l'arbre
<tt>src/</tt>. Cela inclu la prise de d&eacute;cision finale sur les changements
qui sont effectu&eacute;s (et qui resteront) dans la branche -STABLE avant la
mise en place de la nouvelle branche.</p></li>
<li><p>Travailler en coop&eacute;ration avec l'&eacute;quipe principale et/ou la Fondation FreeBSD pour codifier un
ensemble de r&egrave;gles que les revendeurs doivent respecter pour &ecirc;tre autoris&eacute;s
&agrave; appeler un produit "FreeBSD" ou "Version officielle
FreeBSD".</p></li>
<li><p>Tester et int&eacute;grer les paquetages requis &agrave; 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 &agrave; partir des ports pouvant &ecirc;tre redistribu&eacute;s.
re@ est &eacute;galement responsable de la r&eacute;partition de ces paquetages sur les
diff&eacute;rents ISOs en tenant compte des contraintes du support choisi. re@ est
l'ultime responsable pour veiller &agrave; ce que tous les paquetages
n&eacute;cessaires soient disponibles sur le support choisi mais la coop&eacute;ration
de portmgr@ est essentiel.</p></li>
<li><p>Coordination avec le Projet de Documentation FreeBSD pour
s'assurer qu'un ensemble coh&eacute;rent de documentations est fourni avec
la nouvelle version. Cela inclu la possibilit&eacute; de demander qu'aucune
modification importante ne soit faite dans les documentations durant
les semaines qui pr&eacute;c&egrave;dent la sortie d'une version.</p></li>
<li><p>Coordination avec l'&eacute;quipe de l'officier de s&eacute;curit&eacute; afin de s'assurer que
les versions FreeBSD en cours de cr&eacute;ation ne sont pas affect&eacute;es par des failles de
s&eacute;curit&eacute; r&eacute;cemment d&eacute;couvertes. De plus, approximativement une semaine apr&egrave;s la sortie d'une version,
la responsabilit&eacute; de l'approbation des modifications sur la branche <tt>RELENG_X_Y</tt>
est transf&eacute;r&eacute;e de l'&eacute;quipe en charge des versions &agrave; l'&eacute;quipe en charge de la
s&eacute;curit&eacute;. 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&egrave;s. Une annonce
est alors envoy&eacute;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>