Hi Ian, On 6/20/24 23:27, Ian Jackson wrote:
I think *usually* the git history is part of the source, but sometimes it isn't (and sometimes it's even harmful and must be discarded). Usually you wouldn't (and shouldn't) rewrite the history, but sometimes you should (and sometimes you must).
Over time I'd expect that to come up quite a few times, so we need to be organizationally prepared for that -- either have a history redaction team or expect maintainers to be able to do that.
I still have a hard time picturing how this is going to go into practical use over years, especially with rising numbers of users of such a system.
The technical aspect of doing uploads from git is the easy part, but we also need to bring people with various levels of existing git knowledge up to speed on packaging in a git-like environment with several different repository layouts that have subtle differences and pitfalls.
From a didactic point of view, if I had the time to be a mentor, I'd teach "traditional" packaging first, and extend that with git recipes later on, once the basics are there, but obviously that is a non-starter for having people join team-maintained packages.
I don't see a good structured approach to teaching git-based packaging approaches first though, because these would require both marking parts of their existing git knowledge as inapplicable (because it would create a repository structure that doesn't fit the expected layout), and also teaching magic incantations that they have no mental model for yet, to interface with "legacy" systems.
That's why I think having a conceptual split between collaborative maintenance and the public archive makes sense, and abbreviating history in the archive limits the impact of redaction actions: the archive is redacted by ftpmaster, who are generally expected to know what they are doing, and getting the collaborative maintenance repository into a state that allows releases to be made without reuploading the offending blobs should be reasonably easy as well, because if the blob is not part of the current state, it will not be part of the upload.
Also, I think the usefulness of our collaborative maintenance history is overrated -- in those packages where I actually use salsa and git to collaborate, we also have a lot of "fix problem", "actually fix problem", "disable feature for release", "release", "revert 'disable feature for release'" commits that are an accurate audit trail, but less useful as documentation than a squashed history.
Simon
