Bugzilla en français

Original version in English

Ceci est la traduction du courriel envoyé sur la liste de diffusion des développeurs de Bugzilla par Dave Miller, responsable du projet Bugzilla

Futures versions de Bugzilla et recherche d'aide immédiate

Surprise !  Bugzilla n'est pas encore mort. :-)

J'essaie à nouveau de faire bouger les choses sur Bugzilla. La plupart des principaux volontaires ont changé de travail ces dernières années, ce qui leur a laissé moins de temps à passer sur le projet et a ralenti considérablement les choses depuis un certain temps. Pour ceux qui l'ignorent, j'ai fait plus ou moins office de chef de projet depuis quelques années maintenant, sans avoir beaucoup de temps à passer sur Bugzilla, mais sans avoir non plus quelqu'un capable d'intervenir pour me remplacer. J'intervenais seulement pour prendre des décisions quand les autres développeurs étaient dans une impasse. J'ai essayé de remettre le contrôle du projet à quelqu'un d'autre à deux reprises ces dix dernières années, et chaque fois, la personne pressentie a trouvé un nouvel emploi et n'a plus eu de temps à y consacrer, juste avant le passage de témoin. Il faut du temps pour que quelqu'un établisse la confiance nécessaire pour savoir que je le laisse entre de bonnes mains, et donc, sans beaucoup de développeurs actifs, il est difficile de mettre quelqu'un en place pour faire cela. Mais il y a des changements dans ma vie à présent qui me permettent en fait de passer *plus* de temps sur Bugzilla, donc je me remets en selle et je reprends le contrôle direct. Je suis probablement plus intervenu ces trois ou quatre derniers mois que je n'ai pu le faire ces cinq ou six dernières années.

J'ai démarré une nouvelle société de conseiI (pour laquelle je ne peux pas encore faire de publicité car il me reste beaucoup de travail à faire sur le site web d'abord), et j'essaie de la structurer de manière à ce que cela me permette de consacrer à nouveau du temps sur Bugzilla. (Si vous voulez m'engager pour vous aider sur votre installation Bugzilla, ou aider à financer le développement de Bugzilla, n'hésitez pas à me contacter en privé, même si je ne fais pas encore d'annonce publique).

Revenons maintenant aux choses sérieuses et les plans pour ce projet.

[Il y a une demande d'aide dans ce courriel sous les informations de versions. Si vous pouviez nous donner un coup de main, ce serait grandement apprécié. Cela ne concerne pas seulement le code.]

Le scénario pour les versions

J'aimerais publier de nouvelles versions des branches Bugzilla dans les semaines à venir, dès que tout sera en place pour le faire.

La branche 4.4 est maintenue depuis TRÈS longtemps (elle a été initialement publiée en 2013!!!), fonctionne avec des systèmes d'exploitation dépassés, difficiles à trouver ou à installer, encore plus difficile à tester de nos jours, et cela fait longtemps que nous voulons l'abandonner. Mais notre politique de maintenance stipule que nous devons la maintenir encore quatre mois après les deux versions majeures suivantes. La version majeure après la version 4.4 était la version 5.0, et il n'y a pas eu d'autre version majeure après cela, ce qui signifie que le compte à rebours des quatre mois n'a pas encore démarré.

4.4.14 - Je voudrais que celle-ci soit l'ultime version de la branche 4.4 (à moins que des problèmes de sécurité ne soient découverts dans les quatre mois suivants) car la version 5.2 ci-dessous démarrera le compte à rebours des quatre mois.

5.0.4.1 - Pourquoi une version 5.0.4.1 alors qu'il y a une version 5.0.6 ? Si vous avez prêté attention aux notes de version, la version 5.0.5 contenait un changement de schéma massif, ainsi que le reformatage de presque tout le code Perl dans les sources, ces deux changements constituant une violation de notre politique de maintenance pour une branche stable (un responsable des nouvelles versions nouveau dans le processus, n'a pas réalisé cela et a publié les versions, et le temps que nous nous en rendions compte, il était trop tard). Beaucoup de gens l'ont constaté et n'ont jamais fait les mises à jour vers les versions 5.0.5 ou 5.0.6, puisqu'elles ne contenaient aucune mise à jour de sécurité. La version 5.0.4.1 leur permettra d'obtenir les correctifs pour la version 5.0.4 sans les forcer à adopter les changements du schéma.

5.2 - Ce sera la prochaine version majeure et débutera le compte à rebours de quatre mois pour l'arrêt de la branche 4.4. La version 5.2 sera issue de la branche 5.0 après la version 5.0.6 et contiendra les changements de schéma de la version 5.0.5. Par conséquent, si vous avez effectué la mise à jour en version 5.0.6, la mise à jour en version 5.2 sera pour vous l'équivalent d'une mise à jour mineure. Ces changements de schéma auraient provoqué la publication d'une version majeure de toutes façons, il s'agit donc seulement de corriger le problème de numérotation de cette version (la version 5.0.5 aurait dû être numérotée 5.2).

5.9.1 - Ce sera la première version officielle de la branche Harmony et sera classée comme version de développement, à ne pas utiliser en production. C'est ce qui donnera Bugzilla 6.  Le code est suffisamment correct pur être utilisé tout de suite, mais il reste des écueils avant de pouvoir publier cette version pour la mettre en production. Si vous souhaitez aider à la sortie de Bugzilla 6, cette liste de bogues se trouve ici : https://github.com/bugzilla/harmony/blob/main/RELEASE_BLOCKERS.md

Recherche d'aide immédiate

Il y a certaines choses (pas nécessairement relatives au code) pour lesquelles j'aimerais recevoir de l'aide avant la publication des versions ci-dessus.

1. Faire fonctionner les tests (ceci concerne effectivement le code) - les tests automatisés sur GitHub échouent (je pense) sur toutes les branches. Ils ont commencé à échouer sans aucun changement dans notre code (ceci a été découvert quand nous avons essayé d'intégrer tous les correctifs soumis récemment. Les correctifs ont échoué à tous les tests, et quand nous avons essayé sans les correctifs, cela échouait aussi).  Ceci est probablement dû à des changements dans une dépendance utilisée par Bugzilla, car nos instructions d'installation pour les serveurs de test sont : « obtenir les versions les plus récentes de ce paquet » comme dépendance, et non des versions spécifiques. Si quelqu'un a du temps à passer pour essayer d'isoler cette rupture de dépendance et de corriger les tests pour s'en affranchir, ce serait d'une grande aide. C'est en fait la priorité numéro un car tous les correctifs soumis pour Bugzilla sont bloqués à cause de cela. Par conséquent, je travaillerai moi-même là-dessus mais j'aimerais avoir d'autres regards sur ce sujet. Voir également le bogue : https://bugzilla.mozilla.org/show_bug.cgi?id=1785938.
2. Documentation. Ce sera principalement pour les nouvelles branches, mais les anciennes vont avoir besoin d'aide aussi. Surtout pour les instructions d'installation. Les exemples dans la documentation utilisent d'anciennes versions de systèmes d'exploitation, aucune personne sensée n'utilisera de systèmes d'exploitation si vieux pour une nouvelle installation. Par conséquent, les sections concernant l'installation dans la documentation doivent être mises à jour pour utiliser des versions récentes des systèmes d'exploitation dans les instructions et les exemples. Voir également : https://bugzilla.mozilla.org/show_bug.cgi?id=1785943.
3. Audit de conformité de la section 508. Il existe plusieurs agences gouvernementales américaines qui utilisent Bugzilla en interne (la NASA en est un exemple public). Les nouveaux projets gouvernementaux américains doivent se conformer au nouveau guide d'accessibilité de la section 508 de la loi sur les communications. Donc, si vous voulez qu'elles puissent se mettre à jour, nous devons être conformes (au moins sur nos nouvelles versions). Voir : https://section508.gov/. Il existe un modèle pour la déclaration de conformité sur : https://www.section508.gov/sell/vpat/ . J'aimerais que nous trouvions un volontaire pour auditer la conformité sur les branches 5.2 et Harmony, pour ouvrir des bogues pour ce qui rentre en violation et pour déterminer à quel niveau du VPAT® nous en sommes actuellement. Même si nous ne sommes pas encore conformes (je soupçonne que nous ne le sommes pas), j'aimerais être en mesure de faire une déclaration sur la version 5.2 indiquant notre niveau de conformité et la liste de ce qu'il reste à corriger pour être conformes. Voir également : https://bugzilla.mozilla.org/show_bug.cgi?id=1785941

En conclusion…

Si vous pouvez aider sur l'une de ces choses, répondez à ce message, ou rendez-nous visite sur IRC ou Matrix (les liens se trouvent dans la barre latérale gauche sur https://bugzilla.org/) ou ajouter des commentaires dans les bogues indiqués ci-dessus.

--
Dave Miller
Bugzilla Project Lead
https://bugzilla.org/

Original email sent on Bugzilla Developers' Mailing List

Upcoming Bugzilla Releases, and Immediate Help Wanted

Surprise! Bugzilla's not dead yet. :-)

I am trying to kick-start getting stuff moving again with Bugzilla since most of the core Bugzilla volunteers have had job changes over the last few years that have left them with less time to spend on the project, so things have been very slow going for a while. For those that don't know, I've been more or less of a figurehead of a project leader for a number of years now, not having much time to spend on Bugzilla, but not having anyone in a position to be able to step in to replace me, and only stepping in myself to make decision calls when the other developers were at an impasse. I've attempted to hand off control of the project to someone else twice in the last 10 years or so, and both times, the person I was about to hand off to got a new job and didn't have time for it anymore just before we were about to do the handoff. It takes a while for someone to build the trust needed to know I'm leaving it in good hands, so without a lot of active developers it's hard to get someone in place to do that. But I've had some life changes of my own now, which actually give me *more* time to spend on Bugzilla finally, so I'm getting back in the saddle and taking direct control again. I've probably poked at it more in the last 3 or 4 months than I have in the last 5 or 6 years combined.

I have started a new consulting business (which I'm not ready to advertise yet because I still need to do a lot of work on my website first), and I've been trying to structure it in a way that allows me to spend time on Bugzilla again. (If you want to hire me to help with your Bugzilla, or help funding work on upstream Bugzilla, feel free to contact me off-list, even if I'm not publicly advertising yet)

Now back to the nitty gritty and my plans for this project.

[There is a call for help in this email below the release information. If you can give us a hand it would be greatly appreciated. Not all of it is code-related.]

The Release Plans

I would like to put out a new multi-branch release of Bugzilla sometime in the next few weeks, as soon as we can get all the pieces in place to do so.

The 4.4 branch has been on life support for a LONG time (it was initially released in 2013!!!), supports outdated OSes that are hard to find or install, let alone test for these days, and we've been itching to drop it for a long time. But our support policy says that we have to support it for 4 months after the following two major releases. The next major release after 4.4 was 5.0, and there have been no major releases after that, which means that 4 month countdown hasn't even started yet.

4.4.14 - I am intending this to be the final release of the 4.4 branch (barring any security issues being found in the next 4 months) as the 5.2 release below will start that 4 month countdown.

5.0.4.1 - Why 5.0.4.1 when there's a 5.0.6 release? Well, if you paid attention to the change logs, 5.0.5 contained a massive schema change, as well as reformatting almost all of the Perl code in the source, both of which are a violation of our support policy for a stable branch (a new-to-the-process release manager pushed the release out not realizing that, and by the time we caught it, it was too late). A lot of people noticed this and never upgraded to 5.0.5 or 5.0.6, since they didn't contain any security fixes. 5.0.4.1 will give those people additional fixes for 5.0.4 without forcing them to pick up those schema changes.

5.2 - This will be the next major release, and will start the 4 month countdown for discontinuing the 4.4 branch. 5.2 is forked from the 5.0 branch after 5.0.6, and will contain those schema changes from 5.0.5 in it. So if you did upgrade to 5.0.6, 5.2 will be equivalent to a point upgrade for you. Those schema changes should have caused a major release to happen anyway, so this is just fixing the numbering problem with that release (i.e. 5.0.5 should have been called 5.2 to begin with).

5.9.1 - This will be the first official release off the Harmony branch, and will be classified as a developer preview release, not for production use. This is what will eventually be Bugzilla 6. The code is mostly good enough to use right now, but there are still showstoppers to be able to fully release it as a production release. If you're interested in helping make Bugzilla 6 happen, that list of showstoppers is here: https://github.com/bugzilla/harmony/blob/main/RELEASE_BLOCKERS.md

Immediate Help Wanted

There's a few things (not all necessarily code related) that I would love to get help with prior to the above releases.

1. Get Tests Working (this one actually is code related) - the automated tests on GitHub are failing on (I think) all of the branches. They started failing without any changes to our code (this was discovered when we started trying to get caught up on patches people had submitted recently, and the patches all failed tests, and then we tried it without the patches and still failed). This is quite likely due to changes in some upstream dependency that Bugzilla uses, since our installation instructions for the test servers are all "get the most recent version of this package" as a dependency and not specific versions. If anyone has some time to spend trying to isolate this upstream dependency breakage and getting the tests fixed to deal with it appropriately, that would be a big help. This is actually the number one priority because all commits to Bugzilla are currently blocked on it. I will be working on this myself as a result, but I'd love to have a few extra sets of eyes on it. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1785938.
2. Documentation. This is going to be primarily for the newer branches, but the older ones are going to need some help as well. Installation instructions mostly. The examples in the docs use ancient versions of the OSes that are given as sample installs, and no sane person is going to be using an OS that old on a new install. So the installation sections of the docs need to be updated to use modern versions of the OSes in the instructions and examples. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1785943.
3. Section 508 Compliance Audit. There are a number of US government agencies who use Bugzilla internally (NASA is a publicly visible example). New US government projects have to comply with the new accessibility guidelines in Section 508 of the Communications Act, so if we want them to be able to upgrade we need to comply (at least in our newer versions). See https://section508.gov/. There is a template for a compliance statement at https://www.section508.gov/sell/vpat/ . I would love to get a volunteer who could audit the 5.2 and harmony branches for compliance, file bugs for things that are violations, and figure out how much of the VPAT we can actually provide at this point. Even if we're not compliant yet (I suspect we aren't) I would love to be able to provide a statement with the 5.2 release saying how compliant we are, and listing what's left to be fixed to make us compliant. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1785941.

In Conclusion...

If you can help with any of these things, reply to this message, or visit us on IRC or Matrix (links to both can be found in the left sidebar on https://bugzilla.org/) or add comments to the above-listed bugs.

--
Dave Miller
Bugzilla Project Lead
https://bugzilla.org/