[Jack-Devel] Status of the jackaudio.org homepage and releases (good news)

Markus Seeber markus.seeber at spectralbird.de
Wed May 17 10:51:03 CEST 2017


Hello again,

as elaborated in my previous mail (bad news) the jackaudio.org page is
kind of in trouble.

Before these problems can be resolved, there are a few things that have
to be made clear:

1  Who has currently access to the webspace hosting jackaudio.org? I
know Paul has, I think St├ęphane has and somewhere in the back of my head
a voice tells me the Filipe might have access?

2  What I know is, that whoever has access to the webspace of
jackaudio.org has not been monitoring the jack-devel list for my pull
requests. I asked Paul directly and it was done, but I think that should
not be required all the time, so here are some proposals:

2.1  Allow me to access the webspace and do the updates myself. I do not
need a real shell, some kind of file system access should be sufficient.

Pro:
* technically easy, depending on how it's done
* simplifies communication for me (no need to send pull requests to the
List)
* will result in fast updates in the future
* adds no more dependecy on GitHub services
Con:
* trust/security/legal concerns
* shifts more responsibility on me, reduces control for the webspace owner
* still fails in case I am not available

2.2  Set up continuous integration process
GitHub offers an API for interacting with external services in case a
repository is updated. This could be used to deploy changes in the
jackaudio.org repository automatically to the webspace. I would need to
look up how this could work in detail and if there are additional costs
involved. Maybe it can be done in the same way as the ardour.org
homepage is set up?

Pro:
* removes more need for manual intervention in the long run
* no need to authorize additional users to access the webspace
* keeps working even if the maintainers of the website changes
Con:
* requires an external or internal service to be authorized to access
the webspace
* requires some amount of initial setup and testing
* adds a dependecy on GitHub services
* needs documentation and maintenance cost might be to high

2.3  Remove the webspace from the chain completely.
The page will then be hosted only on GitHub pages under the
jackaudio.org domain.

Pro:
* simplifies deployment considerably
* Deployment does not depend on multiple people anymore: faster, less
work hours wasted
* Deployment of updates will be much faster
* more features of the GitHub Pages service can be used, like fetching
repository metadata, hosting of binaries, etc...
* Adding/removing maintainers is easy and handled through access to the
GitHub repository
Con:
* Makes the page dependant on GitHub, if GitHub goes down or evil, so
will the page. Still, it will be possible to host the static page on any
webspace when that happens and just change the domain record.
* Domain owner has less control over the page content.
* Needs some setup by the domain owner, I remember there have been
concerns about the records for mail adresses and the jack mailing lists.
(not entirely sure since the lists seem to sit on a subdomain, this
probably also entails security concerns...)

2.4  Migrate to something completely unrelated. aka Your suggestions?

3  hosting of binaries
This needs input by those who manage the releases of jack1 and jack2
since it is tied into the release process.

What users usually expect is the following ordered by importance
(subjective):
a) one official location for downloads
b) a predictable and consistent naming convention for files and archives
and the contents (especially for packaging)
c) predictable and consistent URLs for all versions and
variants(especially for packaging)
d) complete source tarballs
e) patchnotes
f) additional mirrors
g) checksums
h) release announcement

b, d, e, g, and h are usually provided by the ones responsible for the
releases, the rest depends on which approach was chosen in section 2.
If the webspace is used, I strongly suggest to use it also for the
binries and in case I get access I can offer to put the binaries there
for you in the right place. Otherwise there is the opportunity to create
tags on your GitHub repositories and attach the files there, which is
also a nice place to put checksums, patchnotes and other version
information and also provides automatically a source archive of the
tagged commit.

I will not add the binaries into the repository of the webpage and git
LFS does not sound especially compelling to me too since it requires,
surprise, external hosting of the files anyway and in that case, there
is almost no gain over just using the webspace or the GitHub releases
features.

Dear Paul, dear St├ęphane, dear Filipe,
maybe talk to each other on the LAC about it and come to a conclusion,
because I am at a loss here and can not go any further without your
intervention. It's not the end of the world, but it kind of keeps
bugging me and the users.

best regards
Markus



More information about the Jackaudio mailing list