Manage software maintenance

[benoit74]

Issues like #13 and #17 have proven that we do not achieve to perform regular maintenance of our software despite having opened issues. And I feel like this is true of mostly all software, at least we are not good at managing this. Sometimes we push hard on one system upgrade (like we just did on Zimfarm) but we miss a systematic and systemic approach.

And we also fail to update these issue with precise information as situation evolve.

I feel like a dashboard with all our maintained software and its maintenance status would help.

It would list scrapers, libraries, readers, container images used to run production (e.g. do not forget about PostgreSQL version upgrades), ...

Depending on context, it could list things like:

• language (Node.JS, Python, ...) version used and expected (according to policies / process / goals)
• OS version used and expected
• core dependencies (e.g. for scrapers scraperlib / libzim / browsertrix crawler / wombat / ... ; for frontend Vue.JS and Vuetify ; Django ; ...) version used and expected
• last release date
• last dependencies upgrade
• list of pinned issues and severity typically

I feel like building an automated system to update this dashboard might be tricky, but a quarterly manual update seems feasible. Especially since it leads to a quarterly review and action plan. This review should also lead to determine the effort we want to push to maintain.

Having such dashboard could also help better understand if the situation is getting better or worse. For instance I have the feeling it is getting much worse, but I'm convinced this is only a gut feeling and would deserve a real measurement.

WDYT? I intend to build such a dashboard for my "perimeter" anyway, but would like to gather feedback before doing so and have the opportunity to scale this beyond my "perimeter".

[rgaudin]

I am in favor.
I think it will be very useful to map everything just so the team at large can understand how large our scope is.
It might even show how it evolves (grows mostly).

I'd suggest we start with less information and improve it as we use it.

[kelson42]

To me this is not very clear if the core of the problem is a lack of overview or/and a lack of ressource/priorisation (over new features). Do you have inputs on this question?

[rgaudin]

• we need to update base images for security reasons
• we need to update core libraries/frameworks for security reasons
• we should update core dependencies regularly to not fall behind (and so updating effort stays reasonable)

For this, we need to know when those events should occur. I can't think of a better/easier alternative ATM.

A simple dashboard that lists all independent pieces of software that we maintain, tagged with those upstream images and core-dependency seems relatively easy to maintain.

The dashboard should automatically look into known places to accurately show when we use a version that is EOL (or approaching).

We don't need it to notify us. We just want to be able to glance at it during weekly routine and we'll create tickets where needs be. It won't solve the underlying issue that we don't spend time on maintenance but now you (@kelson42) will be aware and will be able to decide what deserves and update and what doesn't.
I don't think automating it will lead to any improvement as automation means noise and we tend to ignore noise.

We're already informed by dependabot for stuff that has security issues but because it's automated, there's no discussion and thus mostly no action.

[benoit74]

To me this is not very clear if the core of the problem is a lack of overview or/and a lack of ressource/priorisation (over new features). Do you have inputs on this question?

Sorry to say this a bit bluntly, but from my perspective core of the problem is that there is no maintenance management system in place (hence the issue title).

Nobody has "evidence-based" overview of what needs attention in terms of maintenance, how the situation is evolving, where effort should be put, how much resource/budget we need per year, etc ...

Which from my perspective leads to a lack of resource/prioritization, and it is degrading, at least on my perimeter.

But since we have a lack overview of the situation, it stays a personal feeling, difficult to communicate and hard to remediate.

For instance, based on personal feelings we decide to upgrade one system while effort could have been way better spent on something else.

And this feeling is probably partially wrong.

[kelson42]

From both of your feedbacks, I understand that we miss necessary maintenance releases because of lack of "on-time" information about what is necessary to do.

I also understand that you would like to have a better overview about what would need to be done yet or at any point in the future. It's fine to me, but the word "overview" appeals the word "dashboard"... and I have a bit of concern about this approach (cost/maintainability). I would be interested in a lighter alternative.

[benoit74]

By "dashboard" I do not mean a software piece (could develop into this) but a simple Markdown file / wiki article / ... Should we all be in the same room it would have been a physical one, but this is unfortunately not possible (and no, I will not setup a webcam to stream the physical dashboard I would setup at home). Nothing fancy to develop, at least in a first step.

This would miss the automated updates about EOL @rgaudin is mentioning, but if we first focus on core things we know quite well, updates should not be that hard to do by hand.

I would already be very happy if I can share somewhere what I currently discover on my own (e.g. Python 3.14 has been released) and don't know how to report in an easy and effective fashion (creating issues proved to not help).