Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Fedora 25 alpha peut être testée

Charles-Antoine Couret

C'est ce mardi 30 août que les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de l'Alpha de la future Fedora 25.

Malgré les risques concernant la stabilité dune version Alpha, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora 25 et réduisez du même coup le risque de retard. Les versions en développements manquent de testeurs et de retours pour mener à bien leurs buts.

Notons que Wayland est cette fois activée par défaut (pour la version Workstation et lenvironnement GNOME). Ce changement majeur devrait être préservé. Un effort immense a été fait pour gommer les différences fonctionnelles avec la session X.org. Cependant l'expérience utilisateur n'a jamais été aussi respectée qu'avec ces améliorations. En cas de problèmes ou d'un manque important, n'hésitez pas à lancer GNOME avec X.org ce qui est proposé en option dans votre gestionnaire de session (GDM pour Fedora Workstation).

Voici les nouveautés annoncées pour cette version :

Bureautique

  • Cela a déjà été mentionné avec le passage de Wayland par défaut pour la session de GNOME ;
  • Mise en avant de LiveUSBTools pour créer les images installables par clés USB de Fedora sur Windows, Linux et Mac OS X afin de simplifier l'installation de Fedora en utilisant un médium plus populaire que le CD ;
  • Les machines avec deux cartes graphiques (une intégrée et une autre plus puissante, comme sur les portables) seront mieux gérées avec possibilité de mettre la acrte intégrée par défaut, n'activer la carte externe qu'en acs de besoin ou sur demande pour un programme précis ;

Internationalisation

  • L'UNICODE 9.0 fait son entrée ;
  • IBus propose de simplifier la saisie des caractères Emoji ;
  • IBus permet de changer de langue de saisie automatiquement en se basant sur la saisie utilisateur ;

Administration système

  • L'option de systemd KillUserProcesses est activée par défaut ce qui permet de tuer tous les processus de la session d'un utilisateur lorsqu'il se déconnecte ce qui peut avoir des effets de bords avec des connections distants et multiplexeur de terminaux ;
  • La bibliothèque NSS rejoint les politiques de sécurité de GnuTLS et OpenSSL en supprimant les normes SSL 3.0 et RC4 notamment qui sont obsolètes ;
  • Le lien symbolique slogin vers ssh a été supprimé pendant que le script sshd-keygen est supprimé en faveur du service systemd associé ;
  • La bibliothèque Storage remplace UDisk 2 qu'il avait forké par le passé tout en partageant la même API ;

Développement

  • La bibliothèque standard Glibc progresse à la version 2.24 ;
  • Le compilateur d'Haskell passe à la version 7.10 ;
  • Le reluisant langage Perl évolue à la version 5.24 ;
  • Pour les amateurs de JavaScript, c'est Node.js qui utilise la branche 6.x ;
  • Le compilateur pour le langage Rust est enfin disponible ;
  • Le langage Go fonce à la version 1.7 ;
  • Le langage fonctionnel Erlang 19 est à l'honneur ;
  • Le framework Ruby On Rails est sur les rails vers la version 5.0 ;
  • Le langage PHP s'impose avec la version 7.0 ;

Autour de Fedora

  • L'image minimale de base de Fedora ne dispose plus des paquets Perl pour l'alléger et simplifier sa maintenance ;
  • Koji génère maintenant les images installables de la distribution comme les fichiers ISO ;
  • Un nouveau jeu d'utilitaires basés sur Ansible ont été mis en place pour centraliser et simplifier la gestion des tests automatiques qui s'articulaient avant avec des scripts disparates et moins puissants ;
  • L'empaquetage de programmes Python va devenir plus simple en utilisant automatiquement le tag virtuel Provides avec le nom canonique du programme en question ;

Si l'aventure vous intéresse, les images sont disponibles par Torrent. En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Zanata.

Bons tests à tous !

Nouveau serveur et stack LAMP propulsée par Docker !

Guillaume Kulakowski

Afin de réduire les coûts d'hébergement de Scenario-PaintBall, site/forums qui partagent le même serveur que ce blog, nous avons étudié le remplacement de notre vieux Kimsufi 16G à 49€ TTC / mois. En effet, changer de serveur permet (presque) toujours d'avoir un serveur plus récent mais surtout tout aussi voir plus puissant que l'ancien et le tout pour moins cher. Après une rapide étude des solutions du marché, nous avons retenu une Dedibox XC 2016 à 19€20 TTC / mois.

Pour l'occasion j'en ai profité pour refondre complètement l'architecture d'hébergement :

  • Utilisation de CentOS 7 à la place de RHEL 6. Pourquoi passer de Red Hat vers CentOS ? Car, bien qu'en tant que contributeur, j'ai toujours des licences gratuites, je dois les faire renouveler tous les ans et ça me prend du temps et de l'énergie... et je suis fainéant.
  • Activation de SELinux ! Si j'ai déjà sauté le pas sur mes postes de travail (Fedora) depuis bien longtemps, l'ancien serveur était encore en mode désactivé ! Du coup je pourrais arborer fièrement le T-Shirt "setenforce 1" et ainsi faire plaisir à Dan.
  • Utilisation d'un cache HTTP : Varnish.
  • Mise en place d'une stack LAMP full Docker !

Et c'est ce dernier point dont je vais discuter.

docker.png  

Description de la stack LAMP dockérisée

Choix du moteur de stockage

Concernant le choix du moteur de stockage, je ne suis pas parti sur le natif CentOS, à savoir Device Mapper, mais j'ai retenu OverlayFS. J'ai fais ce choix sur les conseils de ce tutoriel et aussi de cette page de la documentation de Docker mais surtout à la lecture de cette phrase :

Many people consider OverlayFS as the future of the Docker storage drive

Gestion de l'envoi des mails et impact sur le réseau

Premier choix qui peut être discuté, j'ai fait le choix de ne pas mettre de container pour envoyer les mails mais d'envoyer les mails directement depuis l'host. En effet, j'ai pour habitude de considérer qu'un serveur doit posséder un MTA, c'est dailleurs une recommandation du Red Hat LSB.

Ceci implique donc que j'ai une communication des containers vers l'host. Comme j'ai un firewall (FirewallD) et que je veux sécuriser les choses au maximum, ceci implique une interface de communication avec un nom fixe. C'est à dire que j'exploite l'interface docker0 et non une interface créée par Compose qui serait créé avec un nom imprédictible (brd-hashquelconque). Du coup pour ouvrir les ports :

# On associe l'interface docker0 à une zone de confiance :
firewall-cmd --permanent --zone=trusted --change-interface=docker0

# On ouvre le service pour cette zone
firewall-cmd --permanent --zone=trusted --add-service=smtp

# On recharge :
firewall-cmd --reload

Pour que Compose utilise le réseau par défaut de docker, appelée "bridge" et utilisant l'interface docker0, il suffit de rajouter la ligne suivante dans Compose :

network_mode: "bridge"

Architecture et typologie de containers

Pour le moment Scénario PaintBall et ce blog partagent les mêmes versions de PHP (5.6) et Apache (2.4). J'utilise donc les mêmes images mais chaque infrastructure possède son propre container apache ainsi que son propre container PHP(-FPM). Bien entendu, un container Varnish mutualisé est présent en amont afin de dispatcher les requêtes sur la bonnes stack mais également pour assurer un rôle de cache HTTP. Concernant la base de données, j'ai fait le choix (discutable là encore) d'utiliser le même container pour les 2 stacks, c'est quand même plus simple à administrer, optimiser, backuper, etc....

De plus, j'ai également fait le choix de ne pas porter les applications Web (IPB, Dotrclear, WordPress) au sein des containers mais au sein de volumes. Ceci me permet de pouvoir mettre à jour les applications directement depuis l'host. Ceci me permet également de faire la migration de serveur plus rapidement.

Schéma d'architecture

Dans un mode 100% Dockerisé, j'aurais 1 groupe de container (Apache, PHP, Memcached, MariaDB, etc...) par application. Dans ce même mode, Dotclear (pour prendre cet exemple), serait présent directement dans les containers PHP et Apache et seul le répertoire public serait un volume partagé. Mais ça me prendrait carrément plus de temps (recréation des containers à chaque mise à jour de Dotclear ou d'un plugin) et le ROI serait négatif car je n'ai pas plusieurs environnements (prod, préprod, etc...), on parle ici d'applications personnelles. Bref, voici à quoi ça ressemble :

Architecture Docker Architecture Docker

Pour ce qui est des containers, j'ai fait un mix entre les containers officiels (MariaDB, Memcached) et des containers personnels (Apache 2.4, PHP 5.6).

Mon docker-compose.yml

Pour lancer mes containers, je suis fainéant, je passe par Compose. J'ai récupéré ma config perso, que j'ai un peu retravaillée :

version: '2'
services:

  ##################################################### Mutualized architecture
  famas_varnish:
    container_name: famas_varnish
    image: million12/varnish
    restart: always
    mem_limit: 1g
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/famas/varnish/conf/default.vcl:/etc/varnish/default.vcl:ro
    network_mode: "bridge"
    ports:
     - 80:80
    links:
     - llaumgui_httpd24:llaumgui
     - radinus_httpd24:radinus

  famas_mariadb10:
    container_name: famas_mariadb10
    image: mariadb:10
    restart: always
    mem_limit: 4g
    env_file:
     - .env
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/famas/mysql:/var/lib/mysql
    network_mode: "bridge"
    expose:
     - 3306

  ######################################################### spb's architecture
  spb_httpd24:
    container_name: spb_httpd24
    image: llaumgui/centos7-scl-httpd24
    build: 
      context: build/httpd/2.4/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/spb:/var/www/spb
     #- /docker/volumes/www/.htpasswd:/var/www/.htpasswd
     #- /docker/volumes/www/challenges:/var/www/challenges
     - /docker/volumes/spb/httpd24/conf/vhost.d:/etc/httpd/vhost.d:ro
     - /docker/volumes/spb/httpd24/conf/ssl:/etc/httpd/ssl/:ro
     - /docker/volumes/spb/httpd24/log/:/var/log/httpd24
    network_mode: "bridge"
    expose:
     - 80
    links:
     - spb_php56:php

  spb_php56:
    container_name: spb_php56
    image: llaumgui/centos7-scl-php56
    build:
      context: build/php-fpm/5.6/
    restart: always
    mem_limit: 2g
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/spb:/var/www/spb
     - /docker/volumes/spb/php56/log:/var/log/php-fpm
    network_mode: "bridge"
    expose:
     - 9000
    links:
     - famas_mariadb10:database
     - spb_memcached:memcached
    extra_hosts:
     - "mail:172.17.0.1"

  spb_memcached:
    container_name: spb_memcached
    image: memcached
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
    network_mode: "bridge"
    expose:
     - 1121

  ##################################################### llaumgui's architecture
  llaumgui_httpd24:
    container_name: llaumgui_httpd24
    image: llaumgui/centos7-scl-httpd24
    build: 
      context: build/httpd/2.4/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/llaumgui:/var/www/llaumgui
     - /docker/volumes/www/.htpasswd:/var/www/.htpasswd
     - /docker/volumes/www/challenges:/var/www/challenges
     - /docker/volumes/llaumgui/httpd24/conf/vhost.d:/etc/httpd/vhost.d:ro
     - /docker/volumes/llaumgui/httpd24/conf/ssl:/etc/httpd/ssl/:ro
     - /docker/volumes/llaumgui/httpd24/log/:/var/log/httpd24
    network_mode: "bridge"
    ports:
     #- 80:80
     - 443:443
    expose:
     - 80
    links:
     - llaumgui_php56:php
     - llaumgui_gitlab:gitlab

  llaumgui_php56:
    container_name: llaumgui_php56
    image: llaumgui/centos7-scl-php56
    build:
      context: build/php-fpm/5.6/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/llaumgui:/var/www/llaumgui
     - /docker/volumes/llaumgui/php56/log/:/var/log/php-fpm
    network_mode: "bridge"
    expose:
     - 9000
    links:
     - famas_mariadb10:database
    extra_hosts:
     - "mail:172.17.0.1"

Conclusion

La nouvelle architecture est en cours de test sur le blog et si c'est positif SPB devrait bientôt nous rejoindre. J'ai également quelques pistes pour améliorer les performances :

  • Réfléchir à l'utilisation d'1 container Postfix.
  • Migrer le blog en PHP 7.

Nouveau serveur et stack LAMP propulsée par Docker !

Guillaume Kulakowski

Afin de réduire les coûts d'hébergement de Scenario-PaintBall, site/forums qui partagent le même serveur que ce blog, nous avons étudié le remplacement de notre vieux Kimsufi 16G à 49€ TTC / mois. En effet, changer de serveur permet (presque) toujours d'avoir un serveur plus récent mais surtout tout aussi voir plus puissant que l'ancien et le tout pour moins cher. Après une rapide étude des solutions du marché, nous avons retenu une Dedibox XC 2016 à 19€20 TTC / mois.

Pour l'occasion j'en ai profité pour refondre complètement l'architecture d'hébergement :

  • Utilisation de CentOS 7 à la place de RHEL 6. Pourquoi passer de Red Hat vers CentOS ? Car, bien qu'en tant que contributeur, j'ai toujours des licences gratuites, je dois les faire renouveler tous les ans et ça me prend du temps et de l'énergie... et je suis fainéant.
  • Activation de SELinux ! Si j'ai déjà sauté le pas sur mes postes de travail (Fedora) depuis bien longtemps, l'ancien serveur était encore en mode désactivé ! Du coup je pourrais arborer fièrement le T-Shirt "setenforce 1" et ainsi faire plaisir à Dan.
  • Utilisation d'un cache HTTP : Varnish.
  • Mise en place d'une stack LAMP full Docker !

Et c'est ce dernier point dont je vais discuter.

docker.png  

Description de la stack LAMP dockérisée

Choix du moteur de stockage

Concernant le choix du moteur de stockage, je ne suis pas parti sur le natif CentOS, à savoir Device Mapper, mais j'ai retenu OverlayFS. J'ai fais ce choix sur les conseils de ce tutoriel et aussi de cette page de la documentation de Docker mais surtout à la lecture de cette phrase :

Many people consider OverlayFS as the future of the Docker storage drive

Gestion de l'envoi des mails et impact sur le réseau

Premier choix qui peut être discuté, j'ai fait le choix de ne pas mettre de container pour envoyer les mails mais d'envoyer les mails directement depuis l'host. En effet, j'ai pour habitude de considérer qu'un serveur doit posséder un MTA, c'est dailleurs une recommandation du Red Hat LSB.

Ceci implique donc que j'ai une communication des containers vers l'host. Comme j'ai un firewall (FirewallD) et que je veux sécuriser les choses au maximum, ceci implique une interface de communication avec un nom fixe. C'est à dire que j'exploite l'interface docker0 et non une interface créée par Compose qui serait créé avec un nom imprédictible (brd-hashquelconque). Du coup pour ouvrir les ports :

# On associe l'interface docker0 à une zone de confiance :
firewall-cmd --permanent --zone=trusted --change-interface=docker0

# On ouvre le service pour cette zone
firewall-cmd --permanent --zone=trusted --add-service=smtp

# On recharge :
firewall-cmd --reload

Pour que Compose utilise le réseau par défaut de docker, appelée "bridge" et utilisant l'interface docker0, il suffit de rajouter la ligne suivante dans Compose :

network_mode: "bridge"

Architecture et typologie de containers

Pour le moment Scénario PaintBall et ce blog partagent les mêmes versions de PHP (5.6) et Apache (2.4). J'utilise donc les mêmes images mais chaque infrastructure possède son propre container apache ainsi que son propre container PHP(-FPM). Bien entendu, un container Varnish mutualisé est présent en amont afin de dispatcher les requêtes sur la bonnes stack mais également pour assurer un rôle de cache HTTP. Concernant la base de données, j'ai fait le choix (discutable là encore) d'utiliser le même container pour les 2 stacks, c'est quand même plus simple à administrer, optimiser, backuper, etc....

De plus, j'ai également fait le choix de ne pas porter les applications Web (IPB, Dotrclear, WordPress) au sein des containers mais au sein de volumes. Ceci me permet de pouvoir mettre à jour les applications directement depuis l'host. Ceci me permet également de faire la migration de serveur plus rapidement.

Schéma d'architecture

Dans un mode 100% Dockerisé, j'aurais 1 groupe de container (Apache, PHP, Memcached, MariaDB, etc...) par application. Dans ce même mode, Dotclear (pour prendre cet exemple), serait présent directement dans les containers PHP et Apache et seul le répertoire public serait un volume partagé. Mais ça me prendrait carrément plus de temps (recréation des containers à chaque mise à jour de Dotclear ou d'un plugin) et le ROI serait négatif car je n'ai pas plusieurs environnements (prod, préprod, etc...), on parle ici d'applications personnelles. Bref, voici à quoi ça ressemble :

Architecture Docker Architecture Docker

Pour ce qui est des containers, j'ai fait un mix entre les containers officiels (MariaDB, Memcached) et des containers personnels (Apache 2.4, PHP 5.6).

Mon docker-compose.yml

Pour lancer mes containers, je suis fainéant, je passe par Compose. J'ai récupéré ma config perso, que j'ai un peu retravaillée :

version: '2'
services:

  ##################################################### Mutualized architecture
  famas_varnish:
    container_name: famas_varnish
    image: million12/varnish
    restart: always
    mem_limit: 1g
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/famas/varnish/conf/default.vcl:/etc/varnish/default.vcl:ro
    network_mode: "bridge"
    ports:
     - 80:80
    links:
     - llaumgui_httpd24:llaumgui
     - spb_httpd24:spb

  famas_mariadb10:
    container_name: famas_mariadb10
    image: mariadb:10
    restart: always
    mem_limit: 4g
    env_file:
     - .env
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/famas/mysql:/var/lib/mysql
    network_mode: "bridge"
    expose:
     - 3306

  ######################################################### spb's architecture
  spb_httpd24:
    container_name: spb_httpd24
    image: llaumgui/centos7-scl-httpd24
    build: 
      context: build/httpd/2.4/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/spb:/var/www/spb
     #- /docker/volumes/www/.htpasswd:/var/www/.htpasswd
     #- /docker/volumes/www/challenges:/var/www/challenges
     - /docker/volumes/spb/httpd24/conf/vhost.d:/etc/httpd/vhost.d:ro
     - /docker/volumes/spb/httpd24/conf/ssl:/etc/httpd/ssl/:ro
     - /docker/volumes/spb/httpd24/log/:/var/log/httpd24
    network_mode: "bridge"
    expose:
     - 80
    links:
     - spb_php56:php

  spb_php56:
    container_name: spb_php56
    image: llaumgui/centos7-scl-php56
    build:
      context: build/php-fpm/5.6/
    restart: always
    mem_limit: 2g
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/spb:/var/www/spb
     - /docker/volumes/spb/php56/log:/var/log/php-fpm
    network_mode: "bridge"
    expose:
     - 9000
    links:
     - famas_mariadb10:database
     - spb_memcached:memcached
    extra_hosts:
     - "mail:172.17.0.1"

  spb_memcached:
    container_name: spb_memcached
    image: memcached
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
    network_mode: "bridge"
    expose:
     - 1121

  ##################################################### llaumgui's architecture
  llaumgui_httpd24:
    container_name: llaumgui_httpd24
    image: llaumgui/centos7-scl-httpd24
    build: 
      context: build/httpd/2.4/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/llaumgui:/var/www/llaumgui
     - /docker/volumes/www/.htpasswd:/var/www/.htpasswd
     - /docker/volumes/www/challenges:/var/www/challenges
     - /docker/volumes/llaumgui/httpd24/conf/vhost.d:/etc/httpd/vhost.d:ro
     - /docker/volumes/llaumgui/httpd24/conf/ssl:/etc/httpd/ssl/:ro
     - /docker/volumes/llaumgui/httpd24/log/:/var/log/httpd24
    network_mode: "bridge"
    ports:
     #- 80:80
     - 443:443
    expose:
     - 80
    links:
     - llaumgui_php56:php
     - llaumgui_gitlab:gitlab

  llaumgui_php56:
    container_name: llaumgui_php56
    image: llaumgui/centos7-scl-php56
    build:
      context: build/php-fpm/5.6/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/llaumgui:/var/www/llaumgui
     - /docker/volumes/llaumgui/php56/log/:/var/log/php-fpm
    network_mode: "bridge"
    expose:
     - 9000
    links:
     - famas_mariadb10:database
    extra_hosts:
     - "mail:172.17.0.1"

Conclusion

La nouvelle architecture est en cours de test sur le blog et si c'est positif SPB devrait bientôt nous rejoindre. J'ai également quelques pistes pour améliorer les performances :

  • Réfléchir à l'utilisation d'1 container Postfix.
  • Migrer le blog en PHP 7.

Fermé pour les vacances

Remi Collet

Je pense avoir bien mérité quelques jours de repos, totalement déconnectés.

Je serais donc absent jusqu'à la fin du mois, et le dépôt ne recevra donc aucune mise à jour avant septembre (e.g. PHP 5.6.25 ou 7..10)

 

Fermé pour les vacances

Remi Collet

Je pense avoir bien mérité quelques jours de repos, totalement déconnectés.

Je serais donc absent jusqu'à la fin du mois, et le dépôt ne recevra donc aucune mise à jour avant septembre (e.g. PHP 5.6.25 ou 7..10).

Soyez patient ;)

PHP version 5.6 requise

Remi Collet

Voir la liste des versions supportées de PHP.

C'est donc désormais la version 5.6 minimum qui est requise pour certains paquets de dépôt remi.

toto requiert php(language) >= 5.6

Bien que de dépôt remi fournisse toujours les paquets de PHP 5.4 et le dépôt remi-php55 ceux de PHP 5.5, et que je prévois de maintenir ces versions encore quelques temps (en rétro-portant les correctifs de sécurité, alors que d'autres dépôts ont simplement prévu de les supprimer), ceci ne correspond pas à l'objectif principal de mon dépôt : fournir les dernières versions de PHP et favoriser leur adoption par les développeurs et les utilisateurs.

De plus en plus de projets ont déjà relevé la version minimum de PHP requise pour fonctionner :

  • phpMyAdmin depuis la version 4.4
  • PHPUnit depuis la version 5.0
  • Laravel Framework depuis la version 5
  • Nette Framework depuis la version 2.4
  • Symfony Framework depuis la version 3.0
  • Zend Framework depuis la version 2.5
  • etc

Maintenir plusieurs versions des applications et bibliothèques et vraiment un boulot énorme. Jusqu'à présent ces versions étant dans le dépôt remi-test, alors qu'elles sont évidement stables. Désormais, elle seront progressivement déplacées dans le dépôt stable.

Si vraiment vous souhaitez continuer à utiliser une ancienne version de PHP:

  • vous devrez vous passer des applications et bibliothèques récents, en empêchant leur installation (directive exclude dans le fichier remi.conf)
  • mettre à jour le PHP du système en version 5.6, et utiliser la SCL pour les sites nécessitant l'ancienne version

Je recommande de prévoir la migration vers une version maintenue :

En particulier, il me semble utile de rappeler que depuis la version 5.4, la compatibilité des nouvelles versions est très bonne, et que la mise à jour est souvent facile (mais nécessite quand même quelques tests).

Je suis un peu triste de voir que les versions non maintenues représentent toujours plus de la moitié des téléchargements (31% pour 5.4, 23% pour 5.5 sur les 2 dernières semaines).

Je comprends que cela ferra plaisir à certains et moins à d'autre, mais j'espère vraiment que cela favorisera la mise à jour vers une version maintenue, et que les statistiques de téléchargement le montreront.

 

PHP version 5.6 requise

Remi Collet

Voir la liste des versions supportées de PHP.

C'est donc désormais la version 5.6 minimum qui est requise pour certains paquets de dépôt remi.

toto requiert php(language) >= 5.6

Bien que de dépôt remi fournisse toujours les paquets de PHP 5.4 et le dépôt remi-php55 ceux de PHP 5.5, et que je prévois de maintenir ces versions encore quelques temps (en rétro-portant les correctifs de sécurité, alors que d'autres dépôts ont simplement prévu de les supprimer), ceci ne correspond pas à l'objectif principal de mon dépôt : fournir les dernières versions de PHP et favoriser leur adoption par les développeurs et les utilisateurs.

De plus en plus de projets ont déjà relevé la version minimum de PHP requise pour fonctionner :

  • phpMyAdmin depuis la version 4.4 (php 5.5)
  • PHPUnit depuis la version 5.0 (php 5.6)
  • Laravel Framework depuis la version 5 (php 5.5)
  • Nette Framework depuis la version 2.4 (php 5.6)
  • Symfony Framework depuis la version 3.0 (php 5.5)
  • Zend Framework depuis la version 2.5 (php 5.5) et pour le version 3.0 (php 5.6)
  • etc

Maintenir plusieurs versions des applications et bibliothèques et vraiment un boulot énorme. Jusqu'à présent ces versions étant dans le dépôt remi-test, alors qu'elles sont évidement stables. Désormais, elle seront progressivement déplacées dans le dépôt stable.

Si vraiment vous souhaitez continuer à utiliser une ancienne version de PHP:

  • vous devrez vous passer des applications et bibliothèques récents, et empêcher leur installation (directive exclude dans le fichier remi.conf)
  • mettre à jour le PHP du système en version 5.6, et utiliser la SCL pour les sites nécessitant l'ancienne version

Je recommande de prévoir la migration vers une version maintenue :

En particulier, il me semble utile de rappeler que depuis la version 5.4, la compatibilité des nouvelles versions est très bonne, et que la mise à jour est souvent facile (mais nécessite quand même quelques tests).

Je suis un peu triste de voir que les versions non maintenues représentent toujours plus de la moitié des téléchargements (31% pour 5.4, 23% pour 5.5 sur les 2 dernières semaines).

Je comprends que cela ferra plaisir à certains et moins à d'autre, mais j'espère vraiment que cela favorisera la mise à jour vers une version maintenue, et que les statistiques de téléchargement le montreront.

 

PHPUnit 5.5

Remi Collet

Les RPM de PHPUnit version 5.5 sont disponibles dans le dépôt remi pour Fedora ≥ 21 et pour Enterprise Linux (CentOS, RHEL...)

Documentation : PHPUnit 5.5 manual et Release Announcement for PHPUnit 5.5.0 (english)

emblem-notice-24.pngCette nouvelle version nécessite PHP ≥ 5.6.

Installation, Fedora :

dnf --enablerepo=remi install phpunit

Installation, Enterprise Linux :

yum --enablerepo=remi,remi-php56 install phpunit

Remarque: cet outil est une pièce essentielle de la QA PHP dans Fedora. Je prévois de mettre à jour rapidement dans les dépôts officiels de Fedora.

PHPUnit 5.5

Remi Collet

Les RPM de PHPUnit version 5.5 sont disponibles dans le dépôt remi pour Fedora ≥ 21 et pour Enterprise Linux (CentOS, RHEL...)

Documentation : PHPUnit 5.5 manual et Release Announcement for PHPUnit 5.5.0 (english)

emblem-notice-24.pngCette nouvelle version nécessite PHP ≥ 5.6 (PHPUnit est disponible dans le dépôt remi, car PHP 5.4 et 5.5 ont atteint leur fin de vie).

Installation, Fedora :

dnf --enablerepo=remi install phpunit

Installation, Enterprise Linux :

yum --enablerepo=remi,remi-php56 install phpunit

Remarque: cet outil est une pièce essentielle de la QA PHP dans Fedora. Je prévois de mettre à jour rapidement dans les dépôts officiels de Fedora. Cette version est aussi disponible dans les dépôts officiels de Fedora pour la version 25 (donc utilisée par Koschei).

PHP version 5.6.25RC1 et 7.0.10RC1

Remi Collet

Les versions Release Candidate sont disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (RHEL / CentOS) afin de permettre au plus grand nombre de les tester. Elles sont  fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests. Uniquement pour x86_64.

Les RPM de PHP version 5.6.25RC1 sont disponibles en SCL et en paquets de base dans le dépôt remi-test pour Fedora21 et Enterprise Linux6.

Les RPM de PHP version 7.0.10C1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-php70-test pour Fedora 21 et Enterprise Linux6.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version.

Installation en parallèle, en Software Collections de PHP 5.6 :

yum --enablerepo=remi-test install php56

Installation en parallèle, en Software Collections de PHP 7.0 :

yum --enablerepo=remi-test install php70

Mise à jour, de PHP 5.6 :

yum --enablerepo=remi-php56,remi-test update php\*

Mise à jour, de PHP 7.0 :

yum --enablerepo=remi-php70,remi-php70-test update php\*

A noter : la version 7.0.10RC1 est aussi disponible dans Fedora rawhide.

emblem-notice-24.pngLa version RC est généralement identique à la version finale (aucun changement accepté, à l'exception de correctifs de sécurité).

Software Collections (php56, php70)

Paquets standards (php)

PHP version 5.6.25RC1 et 7.0.10RC1

Remi Collet

Les versions Release Candidate sont disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (RHEL / CentOS) afin de permettre au plus grand nombre de les tester. Elles sont  fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests. Uniquement pour x86_64.

Les RPM de PHP version 5.6.25RC1 sont disponibles en SCL et en paquets de base dans le dépôt remi-test pour Fedora21 et Enterprise Linux6.

Les RPM de PHP version 7.0.10C1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-php70-test pour Fedora 21 et Enterprise Linux6.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version.

Installation en parallèle, en Software Collections de PHP 5.6 :

yum --enablerepo=remi-test install php56

Installation en parallèle, en Software Collections de PHP 7.0 :

yum --enablerepo=remi-test install php70

Mise à jour, de PHP 5.6 :

yum --enablerepo=remi-php56,remi-test update php\*

Mise à jour, de PHP 7.0 :

yum --enablerepo=remi-php70,remi-php70-test update php\*

A noter : la version 7.0.10RC1 est aussi disponible dans Fedora rawhide.

emblem-notice-24.pngLa version RC est généralement identique à la version finale (aucun changement accepté, à l'exception de correctifs de sécurité).

Software Collections (php56, php70)

Paquets standards (php)

Séparation de F25 et de Rawhide

Charles-Antoine Couret

Ce mardi 26 juillet a été le jour d'une nouvelle étape dans l'élaboration de la prochaine version de Fedora à savoir Fedora 25.

C'est l'occasion où toute l'infrastructure interne du projet et ses contributeurs se mettent en branle pour accueillir une nouvelle branche de développement pour Fedora 25. Cela signifie également que tous les paquets à ce stade sont dupliqués, d'un côté pour Rawhide, de l'autre pour Fedora 25.

Dès maintenant, la mise à jour des deux systèmes sera différente. Les versions des paquets également. Fedora 25 va ainsi poursuivre sa route de stabilisation en suivant tous le processus habituel d'Alpha, Beta et Release Candidates en passant par les journées de tests et autres évènements destinés à améliorer sa qualité.

Pour ceux sur Rawhide, cela signifie devoir faire un choix entre poursuivre les tests de la branche en perpétuelle développement, ou participer à stabiliser Fedora 25. Cela revient à désactiver le dépôt dédié à Rawhide pour activer ceux de Fedora et lancer une synchronisation. Plus l'utilisateur atteint pour changer de voie, et plus le risque de soucis lors de l'opération augmente.

Cette journée est également une autre occasion, celle du tri des fonctionnalités retenus pour Fedora 25. En effet, il y a quelques semaines, les développeurs ont envoyé leurs listes de travaux à effectuer pour cette version. Certains ont été acceptés, d'autres non dès cette étape là.

Tandis qu'aujourd'hui, ceux qui ont été retenus préalablement, devront être testables. C'est-à-dire que l'essentiel de la nouveauté est dore et déjà en place. L'objectif est que les mois restants avant la sortie officielle de Fedora 25 servent à stabiliser ces changements, à les valider. Et pour le faire correctement, il faut du temps. D'où l'importance d'avoir ces fonctionnalités déjà opérationnelles ou presque.

Nous le dirons jamais assez, mais le Projet Fedora est une distribution communautaire où chacun peut apporter sa pierre à l'édifice. N'hésitez pas à installer Rawhide ou la future F25 (ou via une mise à niveau) pour remonter toute anomalie. Plus c'est fait tôt, plus les chances de corrections avant la sortie seront grandes.

PHP en route vers la sortie de la version 7.1.0

Remi Collet

La version 7.1.0beta1 vient juste d'être publiée. C'est maintenant la phase de stabilisation qui commence pour les développeurs, et de test pour les utilisateurs.

Les RPM sont disponibles dans le dépôt remi-php71 pour Fedora 23 et et Enterprise Linux 6 (RHEL, CentOS) ainsi qu'en Software Collection dans le dépôt remi-safe.

 

emblem-important-4-24.pngLe dépôt contient actuellement des versions en cours de développement qui ne sont pas destinées à être utilisées en production.

Lire aussi :

emblem-notice-24.pngInstallation : voir la Configuration du dépôt ou l'assistant de configuration et choisir le mode d'installation.

Remplacement du PHP par défaut du système par la version 7.1 (le plus simple) :

yum-config-manager --enable remi-php71
yum update php\*

Installation en parallèle, en Software Collection de PHP 7.1 (x86_64 uniquement, recommandée pour les tests) :

yum install php71

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.2
  • la version EL6 est construite avec RHEL-6.8
  • de nombreuses extensions sont aussi disponibles, voir la page PECL extension RPM status.
  • suivre les commentaires pour les mise à jour jusqu'à la version finale.

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php70)

PHP en route vers la sortie de la version 7.1.0

Remi Collet

La version 7.1.0beta1 vient juste d'être publiée. C'est maintenant la phase de stabilisation qui commence pour les développeurs, et de test pour les utilisateurs.

Les RPM sont disponibles dans le dépôt remi-php71 pour Fedora 23 et et Enterprise Linux 6 (RHEL, CentOS) ainsi qu'en Software Collection dans le dépôt remi-safe.

 

emblem-important-4-24.pngLe dépôt contient actuellement des versions en cours de développement qui ne sont pas destinées à être utilisées en production.

Lire aussi :

emblem-notice-24.pngInstallation : voir la Configuration du dépôt ou l'assistant de configuration et choisir le mode d'installation.

Remplacement du PHP par défaut du système par la version 7.1 (le plus simple) :

yum-config-manager --enable remi-php71
yum update php\*

Installation en parallèle, en Software Collection de PHP 7.1 (x86_64 uniquement, recommandée pour les tests) :

yum install php71

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.2
  • la version EL6 est construite avec RHEL-6.8
  • de nombreuses extensions sont aussi disponibles, voir la page PECL extension RPM status.
  • suivre les commentaires pour les mise à jour jusqu'à la version finale.

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php71)

Nouveau dépôt "remi-php71"

Remi Collet

Je viens d'ouvrir le dépôt remi-php71 pour Fedora ≥ 23 et pour Enterprise Linux ≥ 6

Ce dépôt contient actuellement PHP 7.1.0beta1 et environ 75 extensions déjà compatibles.

emblem-important-4-24.pngCe dépôt contient actuellement des versions en cours de développement qui ne sont pas destinées à être utilisées en production.

Le configuration est fournit dans la dernière version du paquet remi-release :

  • remi-release-23-4.fc23.remi
  • remi-release-24-2.fc24.remi
  • remi-release-6.8-1.el6.remi
  • remi-release-7.2-1.el7.remi

emblem-notice-24.pngComme pour mes autres dépôts, il n'est pas activé par défaut, la mise à jour est donc une décision de l'administrateur.

Par exemple, pour mettre à jour la version système :

yum --enablerepo=remi update remi-release
yum --enablerepo=remi-php71 update php\*

emblem-important-2-24.pngComme quelques extensions ne sont pas encore disponible, il y a des chances que la mise à jour échoue, il faudra donc supprimer ces extensions ou attendre leur disponibilité.

PHP 7.1 en Software Collection reste dans le dépôt "remi-safe"  puisqu'il n'y a pas de conflit avec la version de base.

 

Nouveau dépôt "remi-php71"

Remi Collet

Je viens d'ouvrir le dépôt remi-php71 pour Fedora ≥ 23 et pour Enterprise Linux ≥ 6

Ce dépôt contient actuellement PHP 7.1.0beta1 et environ 75 extensions déjà compatibles.

emblem-important-4-24.pngCe dépôt contient actuellement des versions en cours de développement qui ne sont pas destinées à être utilisées en production.

Le configuration est fournit dans la dernière version du paquet remi-release :

  • remi-release-23-4.fc23.remi
  • remi-release-24-2.fc24.remi
  • remi-release-6.8-1.el6.remi
  • remi-release-7.2-1.el7.remi

emblem-notice-24.pngComme pour mes autres dépôts, il n'est pas activé par défaut, la mise à jour est donc une décision de l'administrateur.

Par exemple, pour mettre à jour la version système :

yum --enablerepo=remi update remi-release
yum --enablerepo=remi-php71 update php\*

emblem-important-2-24.pngComme quelques extensions ne sont pas encore disponible, il y a des chances que la mise à jour échoue, il faudra donc supprimer ces extensions ou attendre leur disponibilité.

PHP 7.1 en Software Collection reste dans le dépôt "remi-safe"  puisqu'il n'y a pas de conflit avec la version de base.

 

PHP version 5.5.38, 5.6.24 et 7.0.9

Remi Collet

Les RPM de PHP version 7.0.9 sont disponibles dans le dépôt remi-php70 pour Fedora et Enterprise Linux (RHEL, CentOS).

Les RPM de PHP version 5.6.24 sont disponibles dans le dépôt remi pour Fedora ≥ 21 et remi-php56 pour Enterprise Linux.

Les RPM de PHP version 5.5.38 sont disponibles dans le dépôt remi-php55 pour Enterprise Linux.

emblem-important-2-24.pngPHP version 5.5 a atteint sa fin de vie, la version 5.5.38 est donc la dernière mise à jour. Il est donc important de d'envisager la mise à jour en version 5.6 ou 7.0.

emblem-important-2-24.pngPHP version 5.4 a atteint sa fin de vie et n'est plus maintenu par le projet. Compte tenu du nombre important de téléchargements par les utilisateurs de mon dépôt la version présente dans le dépôt remi pour Enterprise Linux (RHEL, CentOS...) a été conservée avec les correctifs de sécurité (de la version 5.5.37). La mise à jour vers une version maintenue est fortement conseillée.

Ces versions sont aussi disponibles en Software Collections.

security-medium-2-24.pngCes versions corrigent quelques failles de sécurité, la mise à jour est donc vivement recommandée.

Annonces des versions :

emblem-important-2-24.png La version 5.5.27 était la dernière mise à jour corrigeant des bugs. La branche 5.5 est donc en maintenance de sécurité uniquement (jusqu'en Juillet 2016).

emblem-notice-24.pngInstallation : voir l'assistant de configuration et choisir la version et le mode d'installation.

Remplacement du PHP par défaut du système par la version 7.0 (le plus simple) :

yum-config-manager --enable remi-php70
yum update

Installation en parallèle, en Software Collections de PHP 7.0 (x86_64 uniquement) :

yum install php70

Remplacement du PHP par défaut du système par la version 5.6 (le plus simple) :

yum-config-manager --enable remi-php56
yum update

Installation en parallèle, en Software Collections de PHP 5.6 (x86_64 uniquement) :

yum install php56

Remplacement du PHP par défaut du système par la version 5.5 (le plus simple) :

yum-config-manager --enable remi-php55
yum update

Installation en parallèle, en Software Collections de PHP 5.5 (x86_64 uniquement) :

yum --enablerepo=remi install php55

Et bientôt dans les mises à jour officielles (Fedora 25 fournira PHP 7.0):

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.2
  • la version EL6 est construite avec RHEL-6.8
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php55 / php56 / php70)

PHP version 5.5.38, 5.6.24 et 7.0.9

Remi Collet

Les RPM de PHP version 7.0.9 sont disponibles dans le dépôt remi-php70 pour Fedora et Enterprise Linux (RHEL, CentOS).

Les RPM de PHP version 5.6.24 sont disponibles dans le dépôt remi pour Fedora ≥ 21 et remi-php56 pour Enterprise Linux.

Les RPM de PHP version 5.5.38 sont disponibles dans le dépôt remi-php55 pour Enterprise Linux.

emblem-important-2-24.pngPHP version 5.5 a atteint sa fin de vie, la version 5.5.38 est donc la dernière mise à jour. Il est donc important de d'envisager la mise à jour en version 5.6 ou 7.0.

emblem-important-2-24.pngPHP version 5.4 a atteint sa fin de vie et n'est plus maintenu par le projet. Compte tenu du nombre important de téléchargements par les utilisateurs de mon dépôt la version présente dans le dépôt remi pour Enterprise Linux (RHEL, CentOS...) a été conservée avec les correctifs de sécurité (de la version 5.5.38). La mise à jour vers une version maintenue est fortement conseillée.

Ces versions sont aussi disponibles en Software Collections.

security-medium-2-24.pngCes versions corrigent quelques failles de sécurité, la mise à jour est donc vivement recommandée.

Annonces des versions :

emblem-important-2-24.png La version 5.5.27 était la dernière mise à jour corrigeant des bugs. La branche 5.5 est donc en maintenance de sécurité uniquement (jusqu'en Juillet 2016).

emblem-notice-24.pngInstallation : voir l'assistant de configuration et choisir la version et le mode d'installation.

Remplacement du PHP par défaut du système par la version 7.0 (le plus simple) :

yum-config-manager --enable remi-php70
yum update

Installation en parallèle, en Software Collections de PHP 7.0 (x86_64 uniquement) :

yum install php70

Remplacement du PHP par défaut du système par la version 5.6 (le plus simple) :

yum-config-manager --enable remi-php56
yum update

Installation en parallèle, en Software Collections de PHP 5.6 (x86_64 uniquement) :

yum install php56

Remplacement du PHP par défaut du système par la version 5.5 (le plus simple) :

yum-config-manager --enable remi-php55
yum update

Installation en parallèle, en Software Collections de PHP 5.5 (x86_64 uniquement) :

yum --enablerepo=remi install php55

Et bientôt dans les mises à jour officielles (Fedora 25 fournira PHP 7.0):

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.2
  • la version EL6 est construite avec RHEL-6.8
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php55 / php56 / php70)

Fin de vie de Fedora 22

Charles-Antoine Couret

Depuis le 19 juillet 2016, Fedora 22 a été déclaré comme en fin de vie.

Qu'est-ce que c'est ?

Un mois après la sortie d'une Fedora version n, ici Fedora 24, la version n-2 (donc Fedora 22) est déclarée comme en fin de vie. Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement supportée pendant 13 mois.

En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora 22 et antérieurs d'effectuer la mise à niveau vers Fedora 24 ou 23.

Que faire ?

Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez téléchargez des images CDs plus récentes par Torrent ou par HTTP.

Il est également possible de faire la mise à niveau sans réinstaller via DNF. Pour cela, taper les commandes suivantes en root dans votre terminal :

# dnf install dnf-plugin-system-upgrade
# dnf system-upgrade download --releasever=23
# dnf system-upgrade reboot

Notez que vous pouvez également passer directement à Fedora 24 par ce biais en changeant le numéro de version correspondante dans la ligne idoine. Cependant cette procédure est plus risquée car moins testée.

La prochaine fois, lors de la fin de vie de Fedora 23, vous pourrez utiliser GNOME Logiciels pour effectuer cette action. ;)" class="smiley

Votez cette semaine pour le FESCo et le Conseil de Fedora !

Charles-Antoine Couret

En ce mois de juillet 2016, comme régulièrement, la communauté de Fedora est invitée à voter pour des postes à des organes décisionnaires du projet Fedora.

En effet, comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council et FESCo. Et ce sont les contributeurs qui décident ! Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au mardi 26 juillet à 2h du matin heure française pour le faire. Donc n'attendez pas trop.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le FAmSCo. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour l'une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

  • Les nouvelles fonctionnalités de la distribution ;
  • Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
  • La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
  • La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège.

Notons par ailleurs que le contributeur francophone Haïkel Guémar renouvelle sa candidature pour ce comité.

Page générée le 05 déc 2016 à 17:43