On Wednesday, August 21, 2024 5:38 PM, Chris Hofstaedtler wrote: >* Simon Richter <sjr@xxxxxxxxxx> [240820 09:11]: >> One of the long-standing issues is that there are multiple ways Debian >> packaging can be represented in a git tree, and none of them are optimal. >[..] >> A possible implementation would be a type of Git "user extension" >> object that contains >> >> - an extension name >> - an object type (interpreted by the extension) >> - type-tagged references to other objects >> - other type-tagged data >[..] > >> Any feelings/objections/missed requirements? > >In the current DEP14/DEP18 discussions a lot of discussion was had about how we >should represent Debian things in git; your mail also goes into this direction. > >My *feeling* is we should do the opposite - that is, represent less Debian stuff in git, >and especially do it in less Debian-specific ways. IOW, no git extensions, no setup >with multiple branches that contain more or less unrelated things, etc. > >I think we should move more towards a setup that is easily understood by people >not closely following our Debian-specific things. We should avoid surprising things, >again that would include the multiple branches and any git extensions. > >Before pushing for new ways of representing Debian stuff in git, I think it would be a >good idea to learn from all the other distros and distro-like systems successfully >using git [1]. Debian is not the only distro that wants to use git to capture changes >and encourage contributions to its packages. On the other side (perhaps), git is increasingly being used in the Ops setting for DevOps and DevSecOps. Production configurations for high-value applications are moving to storing those configurations into git for tracing and audit. Git is an enabler for good production operations practices. My $0.02 (and my customers') --Randall
