fedora 40 and above missing on images on data-analysis.fedoraproject.org/csv-reports/images #12426

New issue

Open

opened 2025-02-27 13:47:51 +00:00 by lnvso · 8 comments

lnvso commented

2025-02-27 13:47:51 +00:00

could fedora 40, 41 and 42 be included in the graphs available at https://data-analysis.fedoraproject.org/csv-reports/images/summary.html

phsmoura commented

2025-02-27 20:14:07 +00:00

Metadata Update from @phsmoura:

Issue priority set to: Waiting on Assignee (was: Needs Review)
Issue tagged with: low-gain, low-trouble, ops

**Metadata Update from @phsmoura**: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: low-gain, low-trouble, ops

phsmoura commented

2025-02-27 20:14:23 +00:00

cc: @james

james commented

2025-02-28 01:40:01 +00:00

I know about the numbers behind this, but not what generates the graphs etc.

cc @mattdm ?

I know about the numbers behind this, but not what generates the graphs etc. cc @mattdm ?

smooge commented

2025-02-28 14:08:36 +00:00

The scripts are a python and awk which do a rough count of 1 entry per arch, release,ip/day and then writes out a csv file. That csv file is then run against some rough gnuplot graphs which get updated daily.

All of these were really a short term hack which turned into a permanent solution so updating to newer releases requires a lot of manual hacking of scripts, gnuplot graphs and the existing CSV files to deal with the newer data. At the moment the only data I would consider it useful for is the EPEL-6,8,9 numbers and historical data for other items.

A better solution would be to finish the 'make a graph every week from the countme data' project and keep an older set of pictures with an end-date of when they were last valid (Jun 2024?).

This is done via a set of scripts not attached to the work James has been doing. The older data graphs were were to be end-of-lifed around Fedora 40 and replaced with ones generated weekly from the dnf countme data. The scripts are a python and awk which do a rough count of 1 entry per arch, release,ip/day and then writes out a csv file. That csv file is then run against some rough gnuplot graphs which get updated daily. All of these were really a short term hack which turned into a permanent solution so updating to newer releases requires a lot of manual hacking of scripts, gnuplot graphs and the existing CSV files to deal with the newer data. At the moment the only data I would consider it useful for is the EPEL-6,8,9 numbers and historical data for other items. A better solution would be to finish the 'make a graph every week from the countme data' project and keep an older set of pictures with an end-date of when they were last valid (Jun 2024?).

kevin commented

2025-03-13 23:29:12 +00:00

The hacky stuff appears to be under roles/web-data-analysis/files/
Perhaps it's not hard to just add 40+ for now?

Or perhaps someone can finish the new thing... but I don't even know the status of that? was someone working on it?

The hacky stuff appears to be under roles/web-data-analysis/files/ Perhaps it's not hard to just add 40+ for now? Or perhaps someone can finish the new thing... but I don't even know the status of that? was someone working on it?

zlopez commented

2025-03-14 08:59:22 +00:00

Contributor

I thought that the new thing is already finished and running.

gwmngilfen commented

2025-03-14 12:26:34 +00:00

Last year, I was playing with a rewrite of https://pagure.io/brontosaurusifier which includes a frontend for the graphs. I didn't finish it then, but (obviously) I kep the code and it probably wouldn't be hard to wrap it up. I could make PR for stg or communishift, if people want me to push on with it.