On 18.02.25 01:06, Charles Plessy wrote:
Hello everybody,

pardon me but I do not see the GCC mass bug filing being discussed on
this list before it was started.

This is nothing new. See https://wiki.debian.org/ToolChain for all bugs filed since GCC 4.9. Do you really want to have a yearly discussion to file these bugs? The difference this year is having more than double of the bug reports compared to GCC 14 last year.

I am usually filing these bug reports once the GCC upstream is in it's final development phase, and the packages are available in experimental.

Give the scale if build failure (hundreds of failures for the Debian Med
packaging team for instance), I want to question if the MBF is
premature.  What other information do we get apart from "most upstreams
are not ready" ?

Just looking at yesterday's replies to bug reports, there are also upstreams listening on the Debian packages, and providing either fixes or notes, which upstream versions fix these issues.

Debian also carries packages which are abandoned upstream, or where Debian is the upstream.

Again, given the scale, Debian can not expect that the package
maintainers are going to contact each upstream and send a patch.  We are
not paid for that.

On the other hand, we also rely on "the ecosystem" to do the work by
themselves so that the packages eventually start to build fine with GCC
15 them after we upgrade them to newer upstream versions.  But who will
close the hundreds of bugs?  I mean, query the BTS, get a bug number,
paste it in a changelog, etc, just to convey information about a change
that did not happen in Debian ?  We are not paid for that.

If that would work, then why do we have still bug reports open filed against GCC 14? I also was fixing GCC 14 issue when working on the Python 3.13 transition? And yes, it's also the Debian Med team which has these kind of bug reports open.

If we want to have stats and know what is the percentage of our pakcages
that adopted GCC 15 compatibility at a given point of time, mass
rebuilds are enough.  Salsa CI also comes to the mind.  But before we
reach the point that we start to track release blockers, I question if
mass bug filings are a tool that makes the best use of our volunteer
time?

stats don't fix bugs, and in the end, these need to be addressed for the forky release. I don't know how much Salsa CI would scale, and how packagers would be notified about these issues.

Matthias

Reply via email to