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

Dear Paul, dear Stéphane, dear Filipe, maybe talk to each other on the LAC about it and come to a conclusion,

Also you can expect a new JACK2 release in the next few days ;)

_______________________________________________ Jack-Devel mailing list Jack-Devel(a)lists.jackaudio.org http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

On 2017-05-22, at 7:08 AM, Filipe Coelho <falktx(a)gmail.com> wrote: Will that include any improved support (any support) for Mac OS after 10.10?

On Tue, 2017-05-23 at 09:37 +0200, David Kastrup wrote: For God's sake, if you're going to change subjects, change subject lines. Why are you running a 32-bit jackd with a 64-bit kernel, and why would you expect it to work?

On 2017-05-22, at 7:08 AM, Filipe Coelho <falktx(a)gmail.com> wrote: Will that include any improved support (any support) for Mac OS after 10.10?

I spoke with Paul about this. He will try to get github hooks working with the current hosting+server to do automatic updates once someone pushes to github. If that doesn't work, we'll sort out something. Likely me doing manual updates from time to time.