Am 05.03.2018 um 14:49 schrieb Martin Owens:
Well there's two portions, the upload part and the releases part. Uploads could be done via scp for bryce, he has ssh access to the webserver. But for others, a token upload would be useful if we want to automate it.
Maybe we could make the webserver pull releases from a fixed location (may it be alpha.inkscape.org or something else)? As far as I understood Bryce giving the release team SSH/SCP access to a directory on alpha.inkscape.org would be a possibility - if the same works for the website server itself it might be even easier.
Either way I support Bryce's earlier statement, that having a fixed location with fixed file names (i.e. no slugs/ids like for website gallery items) that can be updated if need be would be preferential for certain applications (i.e. at the very least for packagers who need to maintain build recipes pulling in the latest source tarball). Probably not so important much for other (binary) releases, though.
The release is trickier because there's fields to fill in, although maybe a way to make a release will fill in fields? Let me know.
Maybe we can (in the above scenario) construct the information from uploaded filenames?
E.g. for a file called "inkscape-0.92.3pre0.tar.bz2" we immediately know it's version 0.92.3pre0 and it's a source tarball. For binary release we could come up with names like "inkscape-0.92.3pre0-win-x86.exe" telling us it's a release for Windows, i686 architecture, exe installer format. Other metadata (license / authors) should be the same for all Inkscape packages. Checksums/signatures could be pulled in from *.md5/*.sig files of the same name, e.g. inkscape-0.92.3pre0-win-x86.exe.md5.
If it's not straightforward to implement that's OK, though... releases don't happen every day, so at least personally I always felt I could invest the few additional minutes.
Am 05.03.2018 um 18:51 schrieb Bryce Harrington:
Perhaps instead, what I could do is along with the file itself, also scp up a YAML descriptive file with metadata. Then the toolage to produce it is entirely on my end, and how it gets digested for display can be dealt with as convenient.
While this sounds absolutely doable I'm not sure if it's not an overly complicated solution? The time every packager needs to invest to construct and update that .yml file properly might be more hassle than it's worth...
Regards, Eduard