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
