[Jack-Devel] Status of the jackaudio.org homepage and releases (good news)
falktx at gmail.com
Wed May 17 12:12:46 CEST 2017
Replying from phone, sorry for top posting... (in the airport now).
When i took over as maintainer of jack1, I specifically mentioned not
wanting to take care of the website.
Tbh i dont know who has access, and I dont think i do.
I did not took over jack2 though, so my own changes there always go through
LAC is here, its the perfect oportunity to talk about this.
@Markus I would be very happy if you took care of the website part of the
jack project :)
On May 17, 2017 09:58, "Markus Seeber" <markus.seeber at spectralbird.de>
> 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.
> * technically easy, depending on how it's done
> * simplifies communication for me (no need to send pull requests to the
> * will result in fast updates in the future
> * adds no more dependecy on GitHub services
> * 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?
> * 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
> * 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.
> * 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
> * 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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Jackaudio