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

[Filipe Lopes]

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
sletz.

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>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20170517/3e690147/attachment.html>