Hi Sean, On Sun, Jun 06, 2021 at 11:40:47AM -0700, Sean Whitton wrote: > If you want to produce patches/commits to share with the maintainer, > then `dgit clone` enables you to work with arbitrary packages in a > homogeneous way, regardless of adoption of `dgit push`. It can also > help you NMU; see dgit-nmu-simple(7). I am not sure what Helmut has in > mind with the mention of .debdiffs -- could you perhaps explain why you > feel you have to fall back to these, even with dgit?
For one thing, you answer your question below and I think this also is what Florian was looking for. There is another issue affecting me, that may derail from the original topic. When I work with packages I tend to fix bugs that are reported by some CI system on unstable. When I dgit clone, I may get the unstable version or I may get unreleased changes that may work or may be broken. That's not what I want. Instead, I strongly prefer working with exactly that version that produced the failure in CI. Even accidentally using experimental often produces wildly differing results. Beyond that, I don't want my trust root for software to reside in SSL certificates. I haven't found a way to ask dgit to produce a git tree that exactly produces the source package signed by unstable reliably. Admittedly, not working with unreleased changes makes integrating them harder for the maintainer. That's certainly a trade-off between my time and their time. I've chosen that I'm unwilling to work with unreleased changes of arbitrary packages. Their quality is too unpredictable to me. > What dgit doesn't really help you with is integrating those patches > directly into the maintainer's repo, if the maintainer invites you to > push your changes directly, which is perhaps what Florian was looking > for. Yes, that. debdiff kinda is the universal format here as it is recommended in the developers reference and can be produced for arbitrary packages. bugs.debian.org is a universal communication method to package maintainers. It's a bit annoying, but universal (inside Debian). Thinking more about this, there is one project of Jelmer that is getting closer to reintegrating changes. It is silver-platter, which really attempts to grok maintainers' idiosyncrasies and produce patches in the way they desire. As far as I know, it actually works with a significant portion of the archive already as it backs janitor.d.n. If everyone was using dgit, then yes it would be providing that homogeneity much like dh does provide homogeneity on the packaging helper level now. The way it currently is, dgit unfortunately is https://xkcd.com/927/ (standards). We really cannot have both workflow diversity and homogeneity. Either of them must be unhappy and dgit chooses not to make the workflow diversity people unhappy. The price for homogeneity is telling a significant number of people that they cannot continue using their workflow and making them very unhappy that way. Helmut
