On Fri, Oct 25, 2024 at 12:55:48PM -0400, Noah Meyerhans wrote: > > > Honestly I'd be happy if we could just establish some expectation that > > > the NMUer open a merge request for their changes. It can be merged > > > later without losing anything or requiring additional work. Enforcement > > > of this expectation would be even better, of course. > > > > the current expectation is that an NMU bug is opened, which contains > > the debdiff. > > > > https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#when-and-how-to-do-an-nmu > > > > "... Then, you must send a patch with the differences between the current > > package and your proposed NMU to the BTS. The nmudiff script in the > > devscripts package might be helpful...." > > Right, and that's not a whole lot more helpful than requiring me to > download the sourcepackage and generate the debdiff myself. Sure all > the content is there, but it's still a tedious amount of work that's > easily forgotten. Further, it loses a little bit of metadata, in that > the git commit now comes from me, rather than the person doing the > actual NMU. > > Yes, I know this is trivial, and yes I know I can fix it with more work; > I don't want NMUs to make more work for me. It makes me not like NMUs.
Sure. We have two options here: make the project do fewer NMUs by doing more maintainer uploads, or standardize and mandate a git workflow or two. We don't like *doing* NMUs either. -- WBR, wRAR
signature.asc
Description: PGP signature
