As underlined by @vlorentz in D6344, we need to define our strategy with storing multiple authors for bzr commits.
Do we use a weaker system like GitHub's co-authored by (https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors) or do we explicitly migrate the existing model to support multiple authors?
| rDLDBZR BZR loader | |||
| D6344 | rDLDBZR04b9a34cf741 Add a non-optimized non-incremental Bazaar loader | ||
Practically, we could be storing the metadata on additional authors *now* in the extra_headers field (make them a bunch of (b'author', b'XXX <yyy@zzz.ttt>') entries). Of course, that doesn't solve the question of presenting the information.
I think having multiple authors in a first-party field in revisions (and releases) will need a revision of our manifest format (which should probably be done with SWHIDv2). The current manifest format mixes authorship and timestamping in the same line, which is less than ideal for making such fields multi-valued.
From merged tasks, this would also be useful for some package loaders, e.g. npm, that support multiple authors in their packaging metadata.
Now that I've written it out loud, of course, Releases don't have extra_headers so the package loaders can't make use of this workaround/hack for now.
Heh :-)
Do you foresee any issue in adding extra_headers to releases as well, other than "someone should do it"?
Not really, no; We've not done it because, afaict, we haven't had a strong need for it. The manifest format should be able to accommodate it even more easily than revisions do (because it has fewer edge cases).
Then let's just go for it (insert here ref. to upcoming separate task :-)).
The added advantage will be that it will make it easier to change "Merkle modeling decisions" in the future, by allowing to more easily switch between release and revision objects. (As we had to do in the past for deposits, for example.)
I suggested Co-Authored-By because it is a de-facto standard in Git now thanks to GitHub, so we already have many revisions using this "format" (no releases as far as I know, though).
Of course it's not great to make the BZR loader write metadata in revision *messages*, but at least it doesn't introduce a new format.