Bonjour 
,
Les curieux aiment toujours savoir ce qu'il va se passer. Pour cela, j'écris ce journal, dévoilant mes plans pour le reste des vacances.
Le thème sera «solidification». Je veux corriger tous les bugs que je peux rencontrer, et certaines choses vont vous plaire.
Les paquets
Pas de nouveaux paquets (sauf peut-être Arora), mais plutôt des corrections, mise à jour, modifications de dépendances, etc.
Ce ne seront pas des semaines très orientées paquets, le reste a plus besoin de moi .
Le site web
Je n'aime pas trois choses dans ce site web, pour le moment :
-
Les commentaires de news et de demandes, qui provoquent un bug et qui sont un peu trop hackish (partage d'une template avec le forum). Je vais voir s'il est possible d'utiliser l'héritage des models pour avoir des tables séparées et adaptées, et une template prenant les bons paramètres. Il faudra aussi des fonctions helper pour ne pas dupliquer le code.
Ainsi, je pourrai retirer plein de hacks du forum et des diverses templates, ce sera largement plus propre .
La gestion des utilisateurs en ligne est, comme tout le monde le sait, assez peu efficace et correcte. Je devrai déboguer un peu tout ça et voir si on ne sait pas le faire rentrer en base de donnée sans trop ralentir le tout.
Ça fait longtemps que je n'ai pas regardé les requêtes lancées. Il faudra que je m'y intéresse, en utilisant également les fonctions .defer() et .only() de Django, pour accélérer le tout.
Le site web sera normalement plus stable et plus efficace.
OpenSuSE Build Service → Logram Build Service
Avec les modifications de la partie ci-dessus, il sera bien plus facile de modifier en profondeur la gestion des paquets.
Pour le moment, j'arrive à gérer les ~700 paquets binaires de la distribution, mais tout doit être fait à la main. Par exemple, hier, j'ai passé OpenSSL en version 1.0.0, ce qui s'accompagne par un changement de nom et de SOVERSIO, (libopenssl.so.0 devient libopenssl.so.1, le paquet libopenssl0 devient libopenssl1, etc).
J'ai du me souvenir et faire des grep sur tous les paquets pour voir lesquels reconstruire. C'est inacceptable, car je ne pourrai pas toujours garder une liste de tous les paquets en local.
Le but de ce module sera une belle administration des paquets, avec un module serveur, reconstruisant automatiquement les paquets quand ils sont modifiés. On pourra aussi s'en servir pour reconstruire les paquets Git, pour qu'ils soient toujours à jour.
Ça permettra aussi de gérer les dépôts, d'envoyer un paquet d'un dépôt à l'autre, etc. Du boulot en perspective, mais j'ai hâte de pouvoir cliquer sur «Reconstruire pour l'architecture : x86_64» 
.
Globalement, je sais déjà plus ou moins comment faire. Un chroot, un unionfs, un bootstrap de Logram, tout ça est relativement facile, surtout que le dépôt est directement sur le serveur (pas de temps de téléchargement). Ensuite, e-mailing au mainteneur si le paquets foire, etc.
Pour finir, pourquoi ne pas utiliser OpenSuSE Build Service ? Parce que ce n'est pas intégré à la v4, et que ça nécessiterait autant de travail de l'adapter que de refaire un machin plus simple et plus adapté à Logram.
Y'a moyen de bien faire°.
°J'ai déjà dit ça deux fois dans l'histoire de Logram. La première a lancé Logram DE, la deuxième Setup .
). Et vue la rapidité de développement en Python par rapport au C++ (ce n'est pas un troll, c'est un avantage de Python mais il n'y a pas que des avantages, cf vitesse d'exécution et gestion des threads), ce serait vraiment plus motivant pour la communauté, non ?
