Re: [Pkg-electronics-devel] Bug#1113417: ponyprog: diff for NMU version 3.1.4+ds-1.1
On Sun, Oct 26, 2025 at 12:51:29PM +0200, Carsten Schoenert wrote:
> Hello Adrian,
Hello Carsten,
> Am 26.10.25 um 12:14 schrieb Adrian Bunk:
> > Dear maintainer,
> >
> > I've prepared an NMU for ponyprog (versioned as 3.1.4+ds-1.1) and
> > uploaded it to DELAYED/2. Please feel free to tell me if I should
> > cancel it.
>
> I can't fully see why you not just provide the patch as a first step to the
> bug report as it's done usually? If the maintainers do not act in maybe 4
> weeks then nobody will be upset if the NMU is done after that time.
> And it's not that this package isn't actively maintained! It's just not my
> highest priority atm to fix these issues on my own, but I'm happily take
> patches!
>
> This way of fixing just creates more work and pressure on my side as I would
> needed to stop the delayed (2 days!) upload (what I don't want to do),
> import your upload in the package git tree and do some after work.
>
> Why you immediately do an NMU? I find this a bit aggressive.
> Don't you trust other maintainers they would pick up your or others patches?
> Collaborative work isn't done this way in my opinion.
the official recommendation would have been to NMU without delay:
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-and-how-to-do-an-nmu
People complaining to me about my delays being too high is also not rare,
my delays are usually higher than recommended and when a package is still
in testing I am usually uploading with a 14 or 15 day delay.
You have not acted on this RC bug for 7 weeks and it has already caused
your package to be removed from testing, but when I upload an NMU to
delayed you are complaining immediately.
An upload to delayed can be taken as a patch by the maintainer, a
maintainer upload is better than an NMU and it is fine when a maintainer
does that or asks me to cancel the NMU or just does the canceling.
An NMU is also not something a maintainer should treat as an insult
when the maintainer did not have time to take care of a bug.
But when the maintainer does not react the default action is the NMU,
without me having to put the package on a list, check that manually,
and touch the package again a few days later.
In the majority of cases there is no reaction from the maintainer,
and the NMU happens after the delay.
I do have zero sympathy when maintainers who have not fixed RC bugs
themselves then demand that I do extra work when fixing their bugs,
like a two-step NMU or doing anything in their git tree or doing
anything based on who the maintainer is.
I am currently fixing RC bugs in ~ 100 packages per week, and this is
far from being enough for being able to keep up with the flood of bugs.
Sometimes there is more work to do for a bug, but it is essential for me
that for a typical GCC 15 or CMake 4 FTBFS like in this case I can do a
reproduce+check_upstream+fix+test+upload+nmudiff cycle in less than
5 minutes and then move to the next package.
This is not the first time people demand I do extra work when NMUing RC
bugs, and I am putting debian-devel in Cc since I would rather spend my
time fixing RC bugs instead of writing such emails again and again.
> Regards
> Carsten
cu
Adrian
Reply to: