Sean Whitton:
Hello,
Hi :)
On Tue 27 Aug 2024 at 09:54am +02, Niels Thykier wrote:# Your views on this ...? Thanks for reading through this and I hope you can help me with the following: 1. Is this problematic for `dgit` to support? 2. Assuming it is problematic, where can we meet to have it palatable for `dgit` while still achieving the principle goal that I want to solve? a. The "no generated artifacts in git" is one I feel strongly for. While I assume it would trivially resolve any concerns from the `dgit` side, I am hoping we can come to a better solution without that one. Like, what would it take for `dgit` to support this without waiving that constraint? b. The "debian/control must be stable" (FTP-master auto-reject) constraint is not in my control to change and does not seem feasible to change either, since the consequences would be unclear for the archive at large.Thanks for working on this. We're certainly interested in packaging UX improvements -- that's much of the point of tag2upload. My first thought is that dgit already has the notion of the maintainer view of a package vs. the dgit view of the package. The former is whatever the maintainer has checked out while preparing their uploads. The latter is what you get with 'dgit clone'. So we could have the maintainer view contain the human-editable file and the generated debian/control would appear in the dgit view.
Somehow I got the understanding that `dgit` had `maintainer view of the package` == `dgit clone view of the package`. Your statement here sounds very promising and like this concept would be compatible with `dgit`. I would be very happy if I had made a misunderstanding. :)
The dgit view is meant to match the archive. I.e., it's got exactly the same contents as the source package. So we would want debian/control committed to it. Is that the sort of committing-of-generated-artifacts you object to? Or is it okay if the maintainer never sees it?
My concern are only about the maintainer repo/mainline branch. If it is not committed to the maintainers mainline branches during regular maintenance nor require extra steps/upkeep of them during upload/release flows, then we should be good. Framed differently, having the files committed or requiring extra steps would be a mental load on the maintainer I want to avoid as I see it as diminishing the value of this proposal.
The maintainer will meet the generated files when merging back an NMU. That is a possible wart of this idea, but I have not found a way around that without breaking the FTP master requirement or my "no generated files in (maintainer's) mainline branch" requirement.
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
