Add a source URL type

[JakobDev]

Most Linux Programs are OpenSource. While smaller Programs use their Repo as Homepage or Link their GitHub issue tracker as Bugtracker, bigger programs does that not. And the Link to the source code is not always prominent on the Homepage, because some Homepages are made for non-programmers. This PR solves this problem. A Link to the source code can be added so users can get there with just one click.

[aleixpol]

+1 I agree this is something appstream is missing.

Maybe it should be called contribute? The sources could also be somewhere with the tarballs.
i.e. for KDE we'd want https://invent.kde.org/plasma/plasma-workspace/, not https://download.kde.org/stable/plasma/5.23.5/

[ximion]

We discussed this before, and this should - if it is implemented - not be implemented as an URL tag, as those are for websites for user information and not potentially machine-readable content like version control data.
Instead, something like this was suggested:

<vcs_browser>https://github.com/ximion/appstream</vcs_browser>
<vcs type="git">https://github.com/ximion/appstream.git</vcs>

However, so far there wasn't really a need to add this as software center authors don't want user to click through to developer websites, developers can find the code easily via the homepage, and automatic Git cloning of projects was also not a feature that people wanted yet.
And I am very hesitant to add features to the specification with a "might be useful" justification, because once something is in, we can not easily remove it again.
So, concretely: How would a feature like this be used, and which software center or other AppStream client tool would consume it?

[cassidyjames]

As an anecdote from the elementary AppCenter side: we frequently see developers putting their GitHub repo as their app's homepage URL in their metainfo, but ideally we'd like to encourage them to use an actual consumer/user-facing website instead of a more developer-oriented code repo. If there were an explicit URL type (however implemented) for them to point to their GitHub repo, it would give our request with the developer a bit more weight, ("Use a user-facing website for your homepage URL, you can set the source URL to your GitHub repo for more technical users/potential contributors!"). In AppCenter, we'd continue to show the homepage URL as-is and likely add a new button for "Source" or "Contribute" or whatever a new URL type was.

I do wonder if we're conflating two different use cases here, though: I know a machine-readable/actionable URL to retrieve the source code has been requested, but I think what's being requested in this issue is a user-facing URL for a specific page/site to encourage contributing. I see both as useful but for different things. For AppCenter, the latter is what's more interesting to me as well, though I see the use of a machine-usable URL for code editors and whatnot.

[JakobDev]

We discussed this before, and this should - if it is implemented - not be implemented as an URL tag, as those are for websites for user information and not potentially machine-readable content like version control data.

This is a link that should be visited by the user and not a machine readable link. It should be shown at the same place as the other links.

However, so far there wasn't really a need to add this as software center authors don't want user to click through to developer websites

With @aleixpol (KDE) and @cassidyjames (elementary OS) we have 2 people who are involved on developing a software center who like this feature. So you can't say that software center authors don't want that. If you open the page of any App with a OpenSource License in Gnome Software, the Software is advertised that the Code is open source and that the Software is developed by a Community. A Link to the source would fit here.

developers can find the code easily via the homepage

In many cases. But are are also cases where this is not the case. If we follow this logic, there is no need for the other types than homepage, because in most cases you can find Bugtracker, Help, FAQ etc. easily via the homepage.

So, concretely: How would a feature like this be used, and which software center or other AppStream client tool would consume it?

A Link to the source is shown at the same place as all the other links. This Link can be clicked by people who want to look at the source code (which are very common in the Linux Bubble) of this exact Application.

Maybe it should be called contribute?

Contribute is not only working with the source. helping translating (for which we already have a Link) is also contribution. There may also be a few rare cases where people make their code public for a audit but don't want contributions.

As an anecdote from the elementary AppCenter side: we frequently see developers putting their GitHub repo as their app's homepage URL in their metainfo,

To be fair, a reason for that could be, that Flathub requires a Homepage Link. If the developer have no Homepage they simple use their Repo as Homepage Link.

[ximion]

Aleix and Cassidy wanting to use it in Discover and AppCenter is indeed a good argument.
I am not convinced that naming an URL type like this "source" is a good idea, as that word is extremely overloaded in AppStream already. Calling the type vcs-browser would IMHO make it much more clear what the purpose of this tag is, pointing to a webpage that lets people browse the VCS source code of this application. Of course, that excludes a directory with source tarballs, but something like that would be less user friendly anyway and I don't think many people would want to point to that (sourcecode may be an alternative that is more precise, but I still like the even more specific variant better).
What do you think?

[ximion]

It would be nice to give an example here at least, as in "link to the source code, for example an online version control system browser."

[JakobDev]

I personally prefer sourcecode.

[JakobDev]

I just saw that appstream-glib had already implemented the source type. It's been there since 22 Jan 2019 . It might bee already used by Software that uses appstream-glib, so I think it's the best to stick with source as name.

[ximion]

I just saw that appstream-glib had already implemented the source type. It's been there since 22 Jan 2019 . It might bee already used by Software that uses appstream-glib, so I think it's the best to stick with source as name.

GNOME Software uses libappstream. And if it's not in the specification it may as well not exist ;-) The "source" thing was implemented for an entirely different, firmware related purpose back then, so no, this will not be named "source" and I have to say after reflecting on it I also really dislike "sourcecode" for a name. From past experience, the more precise a name is, the less issues we will face later with debates of what belongs where and why.

The question that has to be answered first and foremost is "What is this link for?".

• If it is for information on how to contribute to the software, it should be called contribute and likely lead to a website that contains information on how to contribute to the code, artwork, translation etc. of that software.
• If the link is intended to point at an online page to view the source code, it should likely be called vcs-browser and point to Gitlab/Bitbucket/cgit/hgweb pages to let people inspect and download the program's source code.
• If that link is for information on how to develop the software in general (for code only, not artwork etc. as with contribute) it should likely be called development and point to a landing page telling interested software engineers how to obtain the source code and submit patches. This would be the most generic-but-still-specific-enough name.

I think a VCS weblink is what is requested here, or one for development information. From what @cassidyjames said, having a "contribute" option instead might actually turn out to be more useful (and I actually thought that existed already, but I confused it with the "translate" option).

[JakobDev]

The problem I have with vcs-browser is, that are are may cases where the source code is not managed by a vcs. Mostly older programs which offer a source tarball on their website to download. We could also add a contribute type as well.

[ximion]

The problem I have with vcs-browser is, that are are may cases where the source code is not managed by a vcs. Mostly older programs which offer a source tarball on their website to download.

This is explicitly the case I want to avoid for this URL type, because it pushes people into easy-but-wrong patterns where in the end code will be downloaded by scraping the location this URL points to. If someone wants to link a source tarball, using a source type artifact for a release is the much better way to do so ( https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-releases ) - Also, a directory with source tarballs offers no direct way to contribute code back, so it's actually less useful for someone visiting the URL.

[aleixpol]

+1 to focusing on the vcs and the contribution path. The important part is how to join and contribute rather than the source code itself.

[JakobDev]

Sorry being away so long.

+1 to focusing on the vcs and the contribution path. The important part is how to join and contribute rather than the source code itself.

Maybe we should add the two

<url type="vcs-browser">some url</url>
<url type="contribute">some url</url>

[ximion]

I think that's okay for adding contribute and vcs-browser :-) But I guess the former link may be used more often (but software centers could use the latter link as fallback, and with the two tags the specification has enough vocabulary to express the difference between the two for any future use).

[ximion]

Superseded by #392