[AlternC-dev] Session de travail jeudi 26/09

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

alban alban at albancrommer.com
Ven 4 Oct 12:06:11 CEST 2019


Salut,

Merci pour ce rapport et pour le temps que vous avez passé. Il faut
qu'on se croise sur IRC pour parler du merge.

Je réponds à tes questions en sériant les problèmes, désolé si c'est long.


*# Branche/Packaging | Utilisation de la terminologie
"stable/oldstable/oldoldstable"**
*

Je me suis mal exprimé et pourtant Cam m'avait déjà indiqué que c'était
mal formulé, je clarifie :

* Alternc n'utiliserait *QUE* des /n//oms de distribution/ donc /jessie
/ stretch / buster / bullseye // etc.

* Alternc n'utiliserait *PAS*  les termes /stable / oldstable /
oldoldstable/

Je pense que le consensus est établi là dessus.



*# Branche/Packaging | Fonctionnement de la branche master *

Depuis que je connais AlternC, la gestion des branches n'est pas simple,
donc une saine discussion sur la méthode la plus appropriée me semble en
effet critique, et elle implique de se projeter sur le long terme pour
être pertinente.

Corrigez moi si je me trompe mais pour reformuler l'état de la réflexion :

. /Proposition A/ : Utiliser la branche master comme branche de release
pour la distribution Debian «actuelle», ouf, j'ai pas dit /stable/ :).
|_ /Problème A/ :  L'intégration de nouvelles features ne peut être fait
dans la branche master.

/. Proposition B/ : Utiliser la branche master pour recevoir les
features  et une branche «nommée» pour la distribution Debian
«actuelle», comme pour les autres distributions.
|_ /Problème B/ :  La quantité de branches est plus grande que dans la
solution A, donc il faut faut faire plus de merge à chaque nouvelle
feature ou commit de sécurité.

Honnêtement, j'étais instinctivement pour la solution B quand on en a
reparlé et ça se confirme.

Les arguments que je vois pour défendre cette solution B :

 * /Plus intuitive/ : en tant que développeur, je tends à utiliser la
branche master pour les développements ;
 * /Plus lisible/ : une personne qui ne connaît rien du projet, ne
voyant que des branches nommées /stretch /et /jessie/, peut se dire
qu'il n'y a pas de version pour /buster/ ;
 * /Intégration dans le workflow/ : en terme de CI, il faudrait
potentiellement qu'on merge tout nouveau commit dans la branche /master/
pour *chaque* branche de distribution (ex: /nightly_stretch/) et faire
nos tests / builds nightly sur chacune. N'utiliser que des noms de
distribution simplifie ce workflow en évitant d'avoir un /cas particulier/;
 * /Plus simple dans le temps/ : on peut déjà bosser sur une branche
/bullseye/ qui ne repassera par la case /master /quand /bullseye/
devient la distribution «courante» et redevenir /bullseye /quand la
prochaine arrive.
//

Je suis convaincu... donc en avant la discussion ;) d'autant qu'il y a
d'autres facteurs prendre en compte cf. le point suivant.

Je suis convaincu aussi que la documentation formelle et compréhensible
de notre gestion du /workflow/ des branches entre branches de release et
branches de développement est /paramount /dans le projet/:)/

*
*

*# Branche/Packaging | Tag vs. Branche 3.5.rc2
*

En effet, j'ai vu un tag après avoir fait une branche. Honnêtement, je
ne suis pas satisfait de ce que j'ai fait.

Et je ne sais pas mieux comment gérer le problème suivant :

 * On veut avoir une branche qui reçoive les PRs pour un certain état
attendu du projet pour une release particulière, ex. /3.5/
 * On veut avoir des builds pour cet état attendu pour les différentes
distributions, ce qui veut dire une branche par distribution, ex.
/stretch_3.5/

Je n'ai pas de conviction sur le sujet, vos avis plus que bienvenus :)



*# Features 3.5 | SFTP*

Je reconnais qu'on ne devrait pas avoir de features en plus.

D'un autre côté, la gestion de SFTP est en pratique appliquée chez
Octopuce et Webelys depuis plusieurs années.

Dans une version 3.5 qui inclut HTTPS il me semble cohérent d'intégrer
SFTP : le protocole FTP en clair est une faille hyper-critique en 2019.

Rappel : dans openssh 8.0 /The scp protocol is outdated, inflexible and
not readily fixed. We recommend the use of more modern protocols like
sftp and rsync for file transfer instead./

Je pense qu'on peut discuter et voter là dessus mais pour moi c'est une
exception qui est justifiée pour avancer sur ce point de sécurité.

Quels sont vos interrogations précisément sur l'intégration telle
qu'elle est proposée ?

Je trouve que proposer dans la même config FTP / FTPS / SFTP est une
bonne option, non ?


a


On 04/10/2019 00:00, Gabriel Filion wrote:
> Bonjour,
>
> Kienan et moi avons fait une session de travail ajd avec comme focus
> principal de minimiser le plus possible les différences entre la branche
> "koumbit/pu" qui correspond à ce que contient le package alternc de
> Koumbit (pu veut dire Proposed Updates ... nous avons emprunté la
> terminologie du développement du kernel/git) et la branche 3.5.0.rc2
>
> quelques réactions et autres problématiques que nous voulions soulever:
>
> On 2019-10-01 3:20 a.m., alban wrote:
>>   * Nous avons reprécisé la méthode de packaging par branches git et
>>     distribution Debian :
>>       o Les branches des distributions Debian anciennes sont maintenues
>>         en /backportant /les commits de master qui concernent la
>>         sécurité essentiellement//
> super! ça va grandement aider à comprendre ce qui se passe entre les
> différentes branches.
>
>>       o Des branches git spécifiques nommées sont utilisées pour les
>>         distributions Debian anciennes (/oldstable, oldoldstable)
>>         /
>>           + Actuellement /stretch /et /jessie/
> est-ce que le sens de cette phrase est qu'on vuet utiliser le nom des
> releases debian pour les branches? si oui, alors c'est bien et ça rend
> les choses plus claires. si le sens est de proposer d'utiliser
> "oldstable" et "oldoldstable", nous serions plutôt opposé à ces noms de
> branches puisque ça représente une référence qui bouge avec les années.
>
>>       o La branche git /master/ est la branche de la distribution
>>         /stable/ de Debian
>>           + Aujourd'hui, donc, /master == buster/
> ceci semble problématique puisque ça veut dire qu'il n'y a pas d'espace
> pour le développement le plus à jour, par exemple si on commence à
> travailler sur des changements pour une version 3.6.0 future, ou p-e 4.0.0
>
> aussi, la branche "stable" de debian est (tout comme
> oldstable/oldoldstable) un point de repère qui change avec les années.
>
> il serait plus clair d'utiliser une branche "buster" pour la version
> stable présente, qui ne sera plus stable éventuellement.
>
> la branche master devrait être plutôt repréter la version "présentement
> en développement".
>
>
> maintenant, nos questionnements:
>
>  * il y a présentement un tag 3.5.RC2 -- est-ce que ça veut dire qu'il y
> a déjà eu une version rc2 ?
>
>  * nous avons vu plusieurs tickets reliés à l'ajout d'une nouvelle
> feature pour le support de SFTP dans le kanban de 3.5.0. Nous avons
> l'impression que l'ajout de feature ne faisait pas trop partie du focus
> de la release, et nous avons en fait quelques interrogations par rapport
> à la façon dont c'est implémenté. Donc plus de discussion serait
> nécessaire avant d'intégrer cette feature et nous pensons qu'elle
> devrait attendre après la sortie de 3.5.0.
>
>
> _______________________________________________
> Dev mailing list
> Dev at alternc.org
> http://lists.alternc.org/listinfo/dev


-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.alternc.org/arch/dev/attachments/20191004/8c12660d/attachment.html>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 488 octets
Desc: OpenPGP digital signature
URL: <http://lists.alternc.org/arch/dev/attachments/20191004/8c12660d/attachment.sig>


Plus d'informations sur la liste de diffusion Dev