[AlternC-dev] Offre de service de la part d'un revenant

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

Lunar lunar at anargeek.net
Ven 29 Sep 04:02:05 CEST 2006


Le mercredi 27 septembre à 13:15 +0200, larpoux écrivait:
> Après le fiasco du printemps dernier, je reviens vers vous pour vous
> offrir les (maigres) forces de la CNT pour contribuer si possible au
> projet Alternc.
> Tout d'abord je vous présente mes excuses pour ce qui c'est passé en
> mai : il y a eu un certain nombre d'incompréhensions réciproques
> doublées d'une réalité : j'ai *très* mauvais caractère.

Soit, c'est bien de pas refaire non plus les mêmes erreurs de
compréhensions sur comment se déroule les choses *concrêtement*. Voir
plus bas...

> Les modifications suivantes ont été portées sur ce fork :
> 
> - utilisation d'apache2 au lieu du couple apache/apache-ssl
> - rajout d'un "hook" permettant de personnaliser les fichiers
> /var/alternc/apache/... en fonction du site

Je pense que c'est intéressant. Je suis pas sûr que le paquet
apache/apache-ssl survivra après etch. As-tu utilisé les fonctionnalités
de gestion des VirtualHosts du paquet Debian (a2ensite, a2dissite) ?

> - instalabilité sur une Ubuntu 64 bits (ce n'était pas le cas de la 0.9.3)

C'est un avis personnel, mais je ne pense vraiment pas qu'Ubuntu
consistue à l'heure actuelle une bonne distribution à mettre sur des
serveurs. Mes expériences récentes, c'est que systématiquement, dès que
je me suis eloigné des sentiers bien battus, j'ai galéré.

Par contre, c'est important que AlternC fonctionne bien sur Debian
etch, et cette dernière gère tout a fait bien et officiellement
l'architecture amd64.

> - découplage d'alternc et de bind (la CNT n'utilise pas de serveurs de
> noms)

Plus généralement, j'aimerais, pour Globenet, que ce soit généralisé :
que les dépendances aux différents daemons deviennent pour la plupart
des Recommends (au lieu de Depends), afin de pouvoir plus facilement
éclater l'installation sur plusieurs serveurs.

Suffira de bien documenter que dans le cas d'une installation
mono-serveur, un "aptitude install --with-recommends alternc" sera à
utiliser.

Je pense que je renverais un mail à ce sujet plus tard, j'aimerais
mettre à jour l'AlternC utilisé par Globenet et MarsNet entre octobre et
novembre.

> - possibilité pour un compte alternc de gérer des sous-comptes
> (suivant quota), sous forme de ressources

Est-ce facilement désactivable ?

> - gestion des comptes alternc sous forme arborescente

Même question.

> Création de certains modules dont nous avions besoin pour notre intranet:
> 
> - création d'un module "forums" permettant de gérer des forums
> conjointement sous forme de newsgroups-NNTP et de forums PHPBB

Je serais curieux de connaître les outils utilisés pour réaliser la
connexion entre forum et NNTP. M'enfin, je suis pas du tout sûr d'avoir
envie qu'AlternC fasse la promotion de phpBB, usine à trou de sécu et
hackage de site...

> - création d'un module permettant de gérer nos utilisateurs d'une
> manière décentralisée, à l'intérieur de chaque comptes alternc

"Utilisateurs" de quel type ?

> - création d'un module permettant l'accessibilité de certaines
> ressources d'un compte à des utilisateurs d'autres comptes alternc

Ça peut être intéressant aussi. Faut vérifier que tout est bien étanche
néanmoins...

> D'autres modules sont actuellement planifiés:
> [...]

Planifiés par qui ?

> Méthodologie
> --------------
> [...]
>       - Le projet évolue pendant ce temps sans tenir compte du projet
> en cours de développement, car ce dernier n'a pas été réellement planifié
>       - Le projet n'ayant jamais été décidé démocratiquement, rien
> n'est moins sur qu'il réponde réellement aux besoins de la communauté
>       - Le travail d'incorporer ensuite ces développements dans le
> tronc principal n'est pas négligeable et la décision de le faire
> devrait être prise démocratiquement
>       - A l'inverse, certains développeurs décident d'incorporer des
> nouvelles fonctions (commit) dans le tronc principal sans en référer
> aux autres et sans décisions démocratiques (AG, votes, ...)
>       - Et, encore une fois, développer de nouvelles fonctions dans
> une branche (soit-disant) stable ne me conviens définitivement pas

Les « besoins de la communauté », c'est quoi, c'est qui ?
Le développement d'AlternC, jusque là, il est surtout poussé par le
besoin de nos projets respectifs (et je parle de gens qui pondent du
code). Et je trouve que c'est un fonctionnement plutôt pas mal, au
moins, tout ce qui est dans le code, on s'en sert !

*Ta* démocratie, telle que tu la dessines, elle me fait chier. Les
logiciels libres, c'est aussi la possiblité de se faire plaisir, de
faire des trucs utiles, etc. Et sans attendre forcément que tout le
monde est formellement levé la main gauche suffisament longtemps pour
qu'on puisse compter.

Vu que personne bosse a plein temps dessus, qu'on a des usages assez
différents du truc, non, pas besoin d'en référer à tout le monde avant
de faire. Surtout quand l'impact est faible ou qu'on a toujours un suivi
de version ! C'est toujours possible de râler après coup et d'annuler un
commit si vraiment quelqu'un le sent pas du tout.

Enfin, whatever, on a des conceptions de la vie et des pratiques
militantes différentes. Moi, j'ai l'habitude de bosser sur le mode du
« collectif » : pas de vote, discussion jusqu'à établir un consensus
avec engagement formel de personnes dans la réalisation de tâche,
possibilité de rester en dehors (« Je m'en fout, je ferais rien. ») ou
blocage. Dans ce dernier cas, on discute encore ou on abandonne. Et on
essaye de mettre un peu de fluidité là-dedans, pour pas passer nos vies
en réunions.

Note toutefois qu'avant la 0.9.4, il n'était pas
possible de faire des mises à jour proprement par "apt-get upgrade", et
donc la notion de branche « stable » n'avait pas de sens réel alors.

C'est moins le cas maintenant, et piuparts [1] est notre ami.

[1] http://packages.debian.org/piuparts

> - Refaire une branche spécifique à la CNT à partir de quelque chose
> d'à la fois récent et stable (est-ce le cas de ce qui se trouve
> actuellement dans le tronc principal ?)
> - Pour chaque nouvelle fonction nécessaire à la CNT
>        - Faire un document de spécifications clair :-)
>        - Faire lire, amender, et approuver ces specs par l'équipe (qui
> ? Ya-t-il des AG décisionnelles ?)

Tant que personne ne s'y oppose, je vois pas l'intérêt de passer par des
processus formels.

>        - Programmer la fonctionnalité, la tester, et l'archiver dans
> la branche CNT
> 
> Il sera ensuite possible à un grand-gouroo alternc (Anarcat, Benjamin,
> Lunar, ...) de vérifier la qualité de ces patchs et de décider s'il
> faut les intégrer dans le tronc principal.
> Mais si ce n'est pas le cas, ça fait beaucoup de tintouin pour rien!

Bof, j'aurais plutôt envie de voir les patchs arriver sur la liste au
fûr et à mesure pour pouvoir les commenter. Ça vaut sans doute le coup
d'un test définitif avant intégration, m'enfin... 

> Mes questions
> ---------------
> - Est-il réellement souhaitable de gérer une branche CNT, puis, plus
> tard, d'essayer de merger les développements dans le tronc principal,
> au lieu de le faire au fur et à mesure ?

L'idéal, c'est une fonctionnalité par branche. Comme ça, quand c'est
fini, suffit de merger la branche, et zou. C'est comme ça que bosse en
grande partie les gens sur Xorg et Linux, genre.

Après, comme je disais, ce qui nous guide c'est nos besoins, et donc si
la CNT à besoin d'un truc qui tourne même si y a encore des
améliorations envisagées avant une diffusion plus large du code, ça
peut rester une branche à part.

> - Qui voudrait encore être mon "mentor" (tout le monde connait
> maintenant mon

J'ai jamais cru à ce concept. Ma pratique, IRC pour les questions, répond qui
est là et ce sent de le faire, patch envoyé sur la mailling-list et
relectures collectives.

M'enfin, si tu trouves un mentor...

À peluche,
-- 
Lunar                                               http://anargeek.net/
                      ·-|-·hack your mind·-|-·
                                                            weather: fog
Dijon                                                          temp: 9.0 C
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 189 octets
Desc: Digital signature
URL: <http://lists.alternc.org/arch/dev/attachments/20060929/93a55fd5/attachment.pgp>


Plus d'informations sur la liste de diffusion Dev