pkg: Maintainance of external software

[miri64]

I started a discussion in #8728 (comment) regarding maintainance of packages and the transparency of RIOT's packaging system where this software came from.

The problem

In my opinion forking a software into a separate Git repository controlled by the RIOT community requires a certain level of trust by our users that we did not mess with the original piece of software. Additionally, most of our packages (even the ones pointing to the original source) than pick some "random" commit to be the version of the package RIOT uses without any clear indication why this commit was chosen. This leads to very intransparent maintainance steps, when it comes to updating the package, since it isn't immediately clear, what the update includes.

My solution

I propose that we should at least for stable packages (i.e. which have releases and for which in-between these releases there is a clear maintenance process of those releases) we take the original source as upstream (yes even if that means downloading a ZIP file via HTTP; tlsf shows this is doable) and strictly move PKG_VERSION from release to release and provide hot-fixes provided in-between releases as patches. This way both the reviewer of a package update as well as our users can easily track the updates by having a look at the package's release log as well as the hot-fix patches provided.

As far as I remember, our current approach grew

1. out of the need to have the packages source URL reachable at all time, so our CI did not fail because of unreachable resources and
2. because reviewing patches of patches can be confusing.

(1) is nowadays solved since Murdock has some caching mechanisms for both HTTP and Git sources and (2) I can sympathize with, but I don't see it as a reason for denying patches altogether.

[kaspar030]

(2) I can sympathize with, but I don't see it as a reason for denying patches altogether.

Any package maintainer that has to provide patches very probably uses a git repo anyways. Making that public and use it directly saves the trouble of "git format-patch", "git am", ...

Using a commit hash (instead of a possibly changing tag) is necessary so every RIOT commit hash leads to the same sources being built. Using a tag for packages doesn't work here.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.