Hello Helmut, On Sun 06 Jun 2021 at 09:58PM +02, Helmut Grohne wrote:
> 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. I think there is some confusion. 'dgit clone' should always get you what is in unstable, and thus exactly what the CI system was using. It would be a bug if it gave you unreleased changes, and I don't think we've ever seen a bug report like that. (The only exception I can think of is if mirror sync issues interact with your clone, but I think there is code to try to avoid that.) > 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. Yeah. 'dgit clone' is meant to be useful in exactly this situation. >> 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. I think you might be mixing together debdiffs as the universal way to share changes, and the problem of integrating changes into maintainer git trees. The former dgit is useful for -- it can help you produce debdiffs to send to the BTS in a way that's more sane than working with raw source packages outside of VCS. The latter is the harder problem. -- Sean Whitton
signature.asc
Description: PGP signature
