Auto add "the upstream" + salsa repo as another remote

[Christian Ehrhardt ]

Hi,
I know these are clearly feature requests, but I tried to outline my usual manual steps in bugs to provide us a chance to make usd even better.

One thing I do very often is to add the remote of the upstream (the real upstream of the project) to the repo. Now these days there is not a lot you can do, but it would be great to have that remote added (and optionally fetched) at usd clone.

Now how should you know the repo might be the biggest blocker for this, eventually I'd think a debian/control field of the VCS-* scope should become part of the standard.
like VCS-origin (https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields)

OTOH for quite a while we might also just maintain a little mapper of the most common package<->upstreamgit and use that until such a field is available.

Would you consider that useful and worth the effort?

[Nish Aravamudan (nacc)]

I would be hesitant to have any mappings in the repository -- it's too likely to go out of date.

I would be willing to add code to `usd clone` to add a remote for upstream if it can find it from d/control. But note that it's a bit confusing, if, say, upstream changes repositories. And if you switch from, say, ubuntu/devel to ubuntu/trusty-devel and they are using different upstreams -- what should the semantic be?

[Nish Aravamudan (nacc)]

I think I'm coming around to this for well-defined cases.

Rather than 'upstream', I want to incorporate 'rich history' repositories. E.g., if libvirt is maintaining stuff in anonscm, we can add a txt file to the repo that understands that case for libvirt, fetches it during the import and given a suitable mapping (version -> tag in remote) function uses it as a 'rich history parent'.

Ping me next week when you're back from vacation to discuss furhter.

[Christian Ehrhardt  (paelzer)]

Qemu might be a better candidate to get the rich history from anonscm.
And yes I see the point in not generally adding that to all things.

You could even start less invasive by having a ~/.importrc or something like it where users can set up their mappings if they want them.

I'm a bit afraid on the mapping part, essentially you'd want to replace the "imports" of Debian versions and the history in between with tags they have. But then each repo might have a very different tagging scheme. Yet it is surely worth a try IMHO, yet at a lower prio than other stuff you are working on - being already on wishlist that is tagged correctly.

If this becomes widely used one might think about making it more than an optional ~./ conffile, but until then this would be a nice way to work with it for those who want it.

[Christian Ehrhardt  (paelzer)]

While replying I just realized that auto-adding the Alioth git if parsable might be nice as well. But still as before, people can just do so on their own - so this stays wishlist.

[Christian Ehrhardt  (paelzer)]

If we do any of that, adding upstream (if known) and salsa (if derivable from VCS tags) should be done at once. It serves the same purpose.

[Christian Ehrhardt  (paelzer)]

If we make this the default then bug 1874474 gets even more important (give users a choice to want all, medium or just shallow content)

[Andreas Hasenack (ahasenack)]

+1 on this, I find myself always adding those two remotes (salsa and upstream). Could we push for another Vcs-Git/Browser set of tags for upstream, in d/control?

[Bryce Harrington (bryce)]

Fwiw, DEP12 includes provision for a 'Repository' field for the upstream git repo. Not many packages have that specified but that might be a logical place for it.