On Fri, Mar 20, 2026 at 05:46:47PM +0100, Helmut Grohne wrote: > On Sat, Mar 14, 2026 at 01:57:21AM +0000, Mark Brown wrote:
> > I tend to batch up a bunch of stuff approximately once per release cycle > > to collect all the random churn in debehlper and whatever, or when > > there's a new upstream release (as just happened), this fell off the > > list prior to the last release largely due to the difficulty I was > > having understanding the patch. > Your process does not work for me, because it does not address > regressions in a timely manner. To be clear if something like that comes up I generally deal with it more promptly, usually when someone does a transition or something (like with the shambles with the s390 removal). The above is just for the general wishlist packaging change stuff that has nothing in particular attached to it. This is not so far as I have been able to tell a regression fix, this is a new feature which you have requested which isn't so far as I can tell part of anything other than a generalised wouldn't it be nice to have this effort, that seems to fit squarely in that bucket. > Quite clearly your process is also failing, so let us try a different > process. I will escalate this to the CTTE if this is not fixed within a > month and you continue to object to NMUs. Nonetheless I shall continue to attempt to review your changes, apologies for this. Given the urgency I trust that you will respond promptly and clearly to the review feedback below. > did not reply to it for a long time and then kept deferring the matter > unconstructively. I could have easily fixed the issue if you had kept > being silent. It is now that you make it clear that the included cleanup > is your main objection. No, the issue is not doing cleanup. The issue is putting a number of separate, unexplained or poorly explained, changes in a single patch and are then pushing very hard to get them in as is. You can surely see how that both sets off all kinds of alarm bells so I feel I have to review these changes especially carefully (and time consumingly), and also causes me to prioritise other changes. Currently that's mainly the new upstream release. It is an issue with both understanding and trusting the changes. You did provide some more detailed explanations after some prompting, but you did this with a separate somewhat lengthy mail separate mail that needed going over carefully to join it up with the earlier patch in order to provide feedback. There is a reason why the typical flow for code reviews is to split things into patches that make logically distinct changes with individual changelogs, it makes the whole process vastly easier when the changes and their descriptions are directly next to each other. I appreciate that having review rather than just uploading does slow things down, but equally there are things that can be done to facilitate review which do tend to make the whole process flow more smoothly. I do agree that it would have been better to say something about the issues understanding the changes when the bug was first filed but I don't think that removes the desirability of reviewing the changes. > I am now attaching the smallest of patches in two versions to fix the > problem. There are two hunks: A more typical way to present this would have been as three patches, one with the Makefile.am patch, one with the dh_auto_configure change and one with the manual change, each of these with a changelog included as part of the patch. Having the changelog directly next to the change really does help with clarity. > --- a/contrib/minizip/Makefile.am > +++ b/contrib/minizip/Makefile.am > @@ -39,7 +39,7 @@ > EXTRA_PROGRAMS = miniunzip minizip > miniunzip_SOURCES = miniunz.c > -miniunzip_LDADD = libminizip.la > +miniunzip_LDADD = libminizip.la -lz This (from both patches) is patching the upstream source directly without using the package's patch system. Is there some reason for this that I am not aware of or is it just a bug?
signature.asc
Description: PGP signature
