-----------------------------------------------------
Au cours des derniers mois, les équipes chargées de soutenir le projet
Le système d’exploitation FreeBSD a présenté le modèle de support actuel et comment
ce modèle peut être amélioré pour fournir un meilleur support aux utilisateurs de FreeBSD
et les consommateurs.
Les modifications ci-dessous améliorent considérablement le support FreeBSD, réduisent les délais d'exécution
pour les avis d'errata et les avis de sécurité, assure la cohérence entre
des ensembles de paquets binaires et la version du système de base FreeBSD sous-jacent, et
réduire le temps nécessaire pour inclure de nouvelles fonctionnalités dans la version officielle
Ensembles de paquets binaires FreeBSD.
Changements proposés dans un nouveau modèle de support FreeBSD.
---------------------------------------------------------------
Les modifications proposées comprennent:
- Passage d'un modèle de support basé sur une version ponctuelle à un ensemble de versions
à partir d'une branche avec une durée de vie garantie.
- Résolution de la durée de vie arbitraire (et non officielle) de 5 ans de notre succursale
garantie. La politique de support est que la branche stable / X sera
pris en charge pendant 5 ans (minimum) à partir du moment où X.0-RELEASE est publié.
Nous garantissons désormais une durée de vie de 5 ans sur la succursale, quel que soit le nombre
les communiqués sont construits à partir de la branche. En outre, une "dernière minute"
la libération de la branche stable / X ne constitue pas une extension du support
durée de vie de la branche dans son ensemble pour deux années supplémentaires.
- Le responsable de la sécurité ou l’équipe de gestion des ports peut étendre le support à tout
numéro de sortie individuel ou de branche à leur discrétion, en
cas exceptionnels.
- Une nouvelle version stable / de branche ne se produira pas avant deux ans après la
X.0-RELEASE de la branche précédente. Cela limite le nombre de
prises en charge simultanées, ce qui réduira considérablement le coût global
nombre de branches qui doivent être maintenues et testées pour la construction
Avis de sécurité et avis d'errata, réduisant les délais d'exécution.
- Chaque nouvelle version de la branche stable / X obsolète la précédente
relâche sur la branche, offrant une fenêtre de trois mois dans laquelle
les consommateurs sont instamment priés de passer à la dernière version. Pendant Ça
fenêtre de trois mois, les avis de sécurité et les avis d'errata resteront
être publié pour la version précédente, si nécessaire.
Comment ces changements profitent-ils aux consommateurs de
-----------------------------------------------------------
FreeBSD.
--------
Ces modifications apportées à la politique de support de FreeBSD réduiront les délais d'exécution
pour les avis de sécurité et les avis d'errata, fournissez des ensembles de paquets binaires
qui sont plus proches de la dernière version de FreeBSD d’une version donnée
branche, et définissent clairement la durée minimale pendant laquelle une branche
recevoir un soutien.
Quand la nouvelle politique de support de FreeBSD entrera en
-------------------------------------------------------------
vigueur.
--------
Ces changements devraient entrer en vigueur avec FreeBSD 11.0-RELEASE,
qui est encore dans quelques mois.
Les versions de FreeBSD des branches précédentes continueront d’être supportées dans
conformément à la politique qui était en vigueur au moment où ils étaient
libéré.
Déficiences dans le modèle de support FreeBSD actuel.
-----------------------------------------------------
- Le modèle de support FreeBSD est basé sur les versions, plutôt que sur les branches.
Plus précisément, nous déterminons si une version de FreeBSD sera une version normale ou une version normale.
support étendu dans les phases finales du cycle de publication, tandis que
en réalité, nous n'avons aucun moyen de déterminer le succès de la publication.
jusqu'à des semaines ou des mois plus tard.
- Nous ne définissons pas clairement pendant combien de temps la branche stable / X sera supportée
après sa création. Depuis FreeBSD 5.x, nous avons historiquement soutenu une
stable / branche X pendant au moins cinq ans après la publication de la version X.0-RELEASE.
disponible. La durée n'est pas une politique définie, ce qui peut rendre
il est difficile de décider quelle branche suivre.
- Le modèle de support actuel empêche la construction de packages binaires tiers
pour la version la plus récente d'une stable / branche car nous devons
fournir des packages qui peuvent être exécutés sur la plus ancienne version prise en charge de
la branche.
- Les responsables de la maintenance des ports doivent prendre en charge la version la plus ancienne prise en charge sur le système.
branche dans la collection de ports. Ceci ajoute une complexité significative à
l'arborescence en général, mais empêche également l'activation de nouvelles fonctionnalités par défaut.
Un exemple est la mise à niveau vers WITH_NEW_XORG où ces fonctionnalités dépendent
lors de modifications du système de base uniquement disponibles dans X.Z-RELEASE.
- Le modèle de support peut se chevaucher de manière non intuitive, ce qui rend difficile
décider quand évaluer les fonctionnalités de FreeBSD par rapport au calendrier de support de
toute branche donnée. Lorsque les modifications du modèle de support ont été initialement
en cours de discussion, les versions supportées par FreeBSD étaient:
- 8.4-RELEASE: 30 juin 2015
- 9.1-RELEASE: 31 décembre 2014
- 9.2-RELEASE: 30 septembre 2014
(Notez que dans ce cas, la prise en charge de la nouvelle version 9.2 prend fin avant
support de FreeBSD 9.1.)
- Une nouvelle version d'une branche automatiquement ex
tend la durée de vie du support
par deux ans, minimum. Si X.Y-RELEASE était initialement prévu pour être le
version finale de la branche stable / X, c’est un support étendu
libération par définition. S'il est nécessaire de suivre X.Y-RELEASE avec
X.Z-RELEASE pour une raison quelconque, nous aurions deux concurrents
les versions de support étendu de la même branche en séquence. Cela a un
impact sérieux sur la qualité d'une mise à jour lorsqu'il y a plusieurs
versions supportées sur une branche. Le problème s'aggrave lorsque le
La plus ancienne version prise en charge sur la branche a une durée de vie de support plus longue
que la dernière version de la branche.
Éléments clés pris en compte dans les modifications apportées au
-----------------------------------------------------------------modèle de support FreeBSD.
--------------------------
Quelques éléments à inclure dans un nouveau support FreeBSD
le modèle comprend:
- Garantie et indication explicite de la durée de vie du support
stable / branche X dans son ensemble, par opposition à la détermination indépendante de la
durée de vie des versions individuelles de la branche stable / X.
- Fournir des ensembles de paquets compatibles avec la dernière version de
la branche, en veillant à ce que les nouvelles fonctionnalités introduites dans la base FreeBSD
Le système peut être activé par défaut dans les versions de packages binaires.
- Les avis de sécurité et les avis d'errata devraient être mieux alignés entre
src / et ports /. Il existe une liste interminable de cas marginaux avec cette
point particulier, mais considérons une situation où une sécurité critique
la vulnérabilité est découverte, et le code sous-jacent a changé entre
X.Y-RELEASE et X.Z-RELEASE. En plus de la possibilité de
régression dans une (ou les deux) des versions prises en charge en raison de
modifications apportées au correctif de sécurité, il introduit un retard potentiel dans la fourniture
le correctif de sécurité lorsque le nombre de versions prises en charge augmente. Chaque
la version prise en charge ajoute au temps nécessaire pour:
- 1) corriger la vulnérabilité,
- 2) tester le patch,
- 3) vérifier que le correctif est correct, et
- 4) la construction des bits de mise à jour binaire de freebsd-update (8).
Si un problème est découvert à tout moment au cours de l’étape (4), la procédure est réinitialisée.
à l'étape (1). (Il convient de souligner que cela n’est pas dû au manque de
matériel, mais l’ordre dans lequel les différentes étapes de l’émission de sécurité
Les avis et les avis d'errata doivent être émis.)
- Fournir un modèle de support plus facile, plus prévisible et plus facile à
suivre.
- src: "Matthew Seaman": 'Secrétaire de l'équipe principale.'
Mail: "matthew@FreeBSD.org"
Mail: "core-secretary@FreeBSD.org"
Aucun commentaire:
Enregistrer un commentaire