On Tue, Oct 21, 2025 at 10:46:05AM +0200, Andreas Tille wrote: > Hi Adrian,
Hi Andreas, > Am Mon, Oct 20, 2025 at 10:56:38PM +0300 schrieb Adrian Bunk: > > > I think this will not be accepted anyway. I do not see any reason to > > > ask him for canceling. > > > > FTR: > > I do not have a problem with canceling an NMU, and any DD could cancel > > an NMU from DELAYED when there is a reason (and the maintainer upload > > is not anyway faster so that the NMU will just be rejected). > > Thank you for confirming this. I admit I simply consider it an extra > manual step that has no real value once there is a higher version right > inside the archive, thought. Please correct my if you might see this > differently. in the reject case there is no reason to cancel. I was thinking of the case where the NMU is in DELAYED/2 and the maintainer says "I will fix it when I have time next weekend". In that case the maintainer could/should cancel it. >... > > There is even precedent of maintainers doing +exp1 uploads for some > > time every time they are doing an upload to unstable for maintaining > > an experimental-only change until it is ready for unstable. > > I admit I prefer the ~exp1 way ... but this is probably a matter of > taste / team policy. Personally I'd prefer ~exp1 for something that is supposed to be the next upload to unstable soon, and +exp1 (or +test1 or +simde) for "let's try something" experiments. But yes, how experimental is used is for the maintainer to decide. > BTW, as a general note regarding the CMake 4 bugs: I prefered adding > -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to override_dh_auto_configure target > in d/rules over patching. The effect is more or less the same but > works without an additional patch that might need maintenance later. > Do you have any reason to prefer a patch? When a new upstream version fixes it a patch will get dropped during the upgrade, but -DCMAKE_POLICY_VERSION_MINIMUM will stay forever. Your argument is that removing the patch later is work, and my argument is that removing the patch later is better than still having a stale -DCMAKE_POLICY_VERSION_MINIMUM in debian/rules in 25 years. Neither argument is particularly strong. >... > Kind regards > Andreas. cu Adrian
