Thanks a lot for the summary.
Just a minor clarification.
El 10/4/25 a las 9:29, Paul Gevers escribió:
So, back to this case. The original report (1057562) was filed at severity
serious and didn't mention the 1-cpu case.
Did not mention the 1-cpu case because at the time it was failing very
El 10/4/25 a las 13:40, Holger Levsen escribió:
On Wed, Apr 09, 2025 at 02:39:42PM +0200, Santiago Vila wrote:
Remember: we do not hide problems. Somebody should look at this bug
during Bug Squashing Parties, even if it does not make the package
to be removed.
what have severities to do with
On Wed, Apr 09, 2025 at 02:39:42PM +0200, Santiago Vila wrote:
> Remember: we do not hide problems. Somebody should look at this bug
> during Bug Squashing Parties, even if it does not make the package
> to be removed.
what have severities to do with hiding problems?
--
cheers,
Holger
Hi,
On 09-04-2025 21:42, Jeremy Bícha wrote:
On Wed, Apr 9, 2025 at 1:33 PM Paul Gevers wrote:
My personal standard (but with Release Team hat in mind) is that I file
RC bugs about flakiness if a test fails more than about 1 out of 6 times
(on a particular architecture if it's architecture sp
On Wed, Apr 9, 2025 at 1:33 PM Paul Gevers wrote:
>
> My personal standard (but with Release Team hat in mind) is that I file
> RC bugs about flakiness if a test fails more than about 1 out of 6 times
> (on a particular architecture if it's architecture specific).
What about if the failures happe
Hi all,
On 09-04-2025 14:26, Jeremy Bícha wrote:
"flaky" is vague and until there is a specific standard for failure
rate, this is going to be subject to maintainer discretion to some
degree.
My personal standard (but with Release Team hat in mind) is that I file
RC bugs about flakiness if a
On Wed, Apr 9, 2025 at 8:42 AM Santiago Vila wrote:
> What happens in the buildds remains in the buildds. Whoever wants to
> rebuild the package from source will not do so in the official buildds.
>
> You are still violating Policy 4.2 for no particular reason.
>
> If build-time dependencies are s
El 9/4/25 a las 15:07, Jeremy Bícha escribió:
I am willing
to accept a patch to disable that subtest.
Great. Moving the gcr4 part of this -release thread to the bug address,
where I've just posted a patch for your consideration.
Thanks a lot.
The other issue here was the flaky tests in puma,
El 9/4/25 a las 14:26, Jeremy Bícha escribió:
Note that both gcr and gcr4 are key packages, so a serious severity
will not make the package to be removed.
It feels like there is less reason to argue about severity for gcr & gcr4 then?
Less reason to downgrade without asking RMs first, as you
On Wed, Apr 9, 2025 at 7:02 AM Santiago Vila wrote:
> Dear Release Managers:
>
> Based on this reply by Paul:
>
> https://lists.debian.org/debian-devel/2025/04/msg00065.html
>
> I'd like to request that the severity of the following bugs is raised
> to serious again:
> ..
> https://bugs.debian.or
Dear Release Managers:
Based on this reply by Paul:
https://lists.debian.org/debian-devel/2025/04/msg00065.html
I'd like to request that the severity of the following bugs is raised
to serious again:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072535
(Reported by Paul as serious, downg
11 matches
Mail list logo
