Re: [sympa-fr] (question packaging) 2018 hackathon report

[Marc Chantreux <adresse@cachée>]

salut,

semver = https://semver.org/


> "ça juste marche"
> Si on veut ... Par exemple dans la version 6.2.16 actuelle dans stretch
> on a cette régression sur la modération masse de messages.

certes la nouvelle interface fait debat (perso je préférais l'interface
soviétique) mais là encore: le systeme de versionning avec des branches
impaires permettront a ceux qui ont du temps de mettre en évidence ce
genre de problemes fonctionels qui seront donc corrigés au moment d'un
passage a la version stable (ca c'est la théorie: en pratique ca ne
marche que si il y a assez de serveurs qui suivent les versions impaires
et ce sera le cas de quelques grosses instances je l'espere).

> C'est relativement pénalisant. Sans prendre en compte l'alerte de
> sécurité récente, même si celle-ci peut-être corrigée en appliquant un
> patch à même les fichiers installés par les paquets (ce que
> normalement, la bonne pratique n'invite pas à faire).

la encore: le semver devrait régler le pb puisque les patches seront
inclus dans sympa dans les patchlevels et donc poussés dans les
distributions stables.

alors du coup je reformule "ca juste marche" est plutot "ca juste aurait
du marcher" si on avait appliqué le semver comme ca avait été décidé au
hackathon de l'an dernier ... sauf que

a l'époque:

* je ne savais même pas que ca s'appellait le semver et je n'avais pas
  conscience que les vertues de ce genre de versionning pouvaient être
  sujet à debat.
* il n'y avait personne a Renater pour suivre ce dossier
* le release manager nommé alors par la communauté (qui s'averait être
  de loin le contributeur le plus actif à l'époqu) n'a pas compris ou
  pas suivi ce schéma de version. c'est d'autant plus grave à mes yeux
  que les numéros de version laissent à penser qu'on utilise bien semver
  (quand je vois 6.2.x, j'imagine immédiatement que x est le patchlevel
  ce qui n'est toujours pas le cas dans sympa).
* je n'ai fais que reporter des décisions au fil de l'eau sur
  sympa-developpers

cette fois-ci:

* il y a deux personnes à Renater pour suivre ça
* luc (framasoft) est rentré dans la boucle et a même poussé plus loin
  la discutions sur la gouvernance (roadmap tout ca ...)
* David qui a été mandaté officiellement pour rendre compte des décisions
  prises
* il a la légitimité et la diplomatie dont j'ai manqué pour faire passer
  certaines pilules à tous les développeurs.

donc nous sommes maintenant dans une situation ou "juste ca aurait du
marcher" devrait se transformer en "juste ca marche".

> Je m'interroge : ont-elles plus de temps dans l'absolu ou décident-elle
> d'en consacrer plus par nécessité, du fait qu'elles ont besoin d'avoir
> les derniers fix divers ?

ce sont les besoins internes qui définissent la politique en fonction de
ce que fournit le projet. pour le moment:

* soit tu as installé un paquet debian qui te convient et je dirais de
  ne pas bouger.
* soit tu dois upgrader et il te faut passer par les sources. il faut
  alors demander (sur cette liste par exemple) a partir de quelle
  version le bug qui t'impacte est corrigée et quelle version égale ou
  superieure à celle-ci est conseillée ... parceque oui: le release
  management n'est pas notre fort actuellement ...et j'en suis le
  premier désolé ...

> C'est toujours plus facile et plus rapide de maintenir une appli
> packagée qu'une appli installée à la main.

certes ... mais ca te contraint à la politique du mainteneur.
dans la situation actuelle, nous devrions peut-être effectivement
créer un depot alternatif à debian pour maintenir une version
que nous pensons être le meilleur compromis entre stabilité et
fiabilité mais ... qui s'y colle?

> Pour moi c'est une évidence,
> mais j'entends d'ici les cloches de docker sonner... Ca me ferait un
> peu suer d'avoir à installer un container docker en prod pour Sympa.

oui mais y'en a qui pensent plus que par le cloud et sympa veut être
sympa avec tout le monde :) bon apres ca aurait un veritable intéret
par exemple de pouvoir expliquer a kubernetes comment il peut gérer
comme un grand le nombre de process bulk.

> La façon donc est distribué/installé/mis à jour Sympa reste une question
> très importante.

oui mais elle est subordonnée pour moi à la question du semver.

> Néamoins je reste tout à fait sceptique quant à la multiplication des
> méthodes d'installation et de mise à jour.

perso je pense qu'on devrait officialiser/afficher que debian est notre
os de référence et concentrer nos efforts dessus (vu que ubuntu ne fait
que suivre debian, on aurait le gros des users, je pense). mais je ne
sais meme pas ce qu'en pense le reste de la communauté.

> Plus ou moins... Faudra quand même faire de la maintenance sur les
> paquets des distribs ne serais-ce que pour les maj de sécu.

la maintenance est deja faite pour debian (racke est le mainteneur
officiel du paquet) et le release manager officiel maintient aussi
les rpms.

> Juste pour être sur d'avoir bien compris, l'idée est de prendre en
> charge uniquement les "backward-compatible bug fixes" dans les versions
> LTS des distribs ?

c'est ca! je t'encourage a lire le lien en début du message et tout sera
clair :). comme je le disais: on aurait du adopter ce modele l'an
dernier et la situation actuelle n'est que conjoncturelle. j'ai
probablement péché par optimisme sur nombre de sujets au sortir du
hackathon 2017 et le retour de David change bien des choses ... qu'il le
veuille ou non, qu'on le dise ou non: c'est lui le capitaine de ce
navire et il est très à l'écoute de son équipage.

cordialement,
marc