Hello users and developers of JACK,
recently, there have been a lot more questions and remarks about the
jackaudio.org homepage and the releases, especially of jack2.
Since most of these questions and remarks are entirely justified, this
mail (bad news) will provide some insight I have about the current
situation of the page, the release process and how all these things did
happen up to now. This is a long mail, only read it if it is really
relevant to you.
1 the page
The main part of the current homepage for JACK ( jackaudio.org ) is a
set of static html pages, generated from markdown files with jekyll .
The whole build process for the static page is compatible to the GitHub
pages  infrastructure, which means it can be built completely with
and without GitHub and as well as deployed as a GitHub page. Further
details can be obtained from the README in the GitHub repository. The
page also contains a html version of the JACK API documentation and some
of the tutorials and Information were moved to a Wiki provided by
GitHub. The sources for the page are hosted as a dedicated repository
on GitHub under the jackaudio organization, together with jack1 and
jack2. Attached to the repository, you can also find the mentioned
Wiki. There is also a dedicated bug tracker for the page attached to
the repository of the homepage on GitHub.
2 webpage hosting
The page is currently hosted on a webspace owned by Paul Davis, who also
owns the jackaudio.org domain. To my best knowledge, only Paul and
Stèpahe Letz have currently access to the webspace. Hosting the page on
this webspace instead of using the GitHub pages infrastructure directly
was a decision made for various reasons.
The domain is also associated to the jack mailing lists which made it
difficult at that time (2014) to point the domain to GitHub pages instead.
Having a page that was not dependent on the GitHub pages infrastructure
was a requirement at the time we transitioned from a broken and hacked
Drupal installation to a static page.
3 webpage development and deployment
The GitHub repository is currently maintained by me with help in form of
bug reports, pull requests and edits of the wiki from the community. If
I determine (by the rule of thumb) that enough changes to the page have
accumulated or a release of jack1 or jack2 occurs, I prepare the page to
be pulled and basically send a pull request to the jack-devel mailing
list, signalling that the github repo should be pulled to the webspace.
Since the page is designed in a way to be compatible with GitHub pages
and already set up to work as a GitHub page, it became accessible under
the github domain , which was nice for development purposes and was
supposed to serve as a preview before pulling changes to the webspace.
4 The case of JACK release binaries
The page also links to release binaries and source tarballs of jack1 and
jack2 (at least it's supposed to). These binaries are not included in
the git repository since having multiple large binaries inside the
repository would make it unfriendly to clone, especially after a few
releases. Multiple approaches to hosting the binaries have been
discussed. Paul did upload the binaries for jack1 to the mentioned
webspace after a release. For jack2, Stéphane decided to use DropBox
public files to host the release binaries. The use of tags on the
respective repositories of jack1 and jack2 was discussed multiple times.
Attaching the release binaries to tags could have solved the hosting
problem. Still, there was the requirement to be independent from GitHub
so this idea was not followed through. Also GitHub LFS was considered
but wasn't ready and released by GitHub in 2014/2015 and also wouldn't
really have resolved the issue of depending on GitHub, since the files
would have still been hosted on GitHub infrastructure. On a new release,
the maintainers would announce new links to the binaries and I would
update the site accordingly. It required manual intervention but since
release cycles were already long I wasn't too worried about that.
5 how it all came down
Over time minor challenges arose. Sometimes it was just GitHub changing
some configuration for their jelkyll configuration, sometimes DropBox
would limit the number of Downloads, sometimes it would take a few days
longer or required a second reminder to get my changes puled to the
webspace. At some point Paul decided to step down as the lead developer
of jack1 but keeping the webspace and the domain online. Reaction times
for getting changes to the webspace became longer (at least it felt like
that to me) and then also DropBox terminated their free hosting of
public shares. At that point a lot of people were also asking for an
update of the jack2 installer on OSX. The whole thing resulted in
multiple questions on the mailinglists, reports in bugtrackers all over
place on lists and bugtrackers I didn't even knew I was subscribed to,
someone even managed to use the review feature on a commit of the jack
repo. I did some mitigation on the bugtrackers and after some time went
by I made a grave mistake.
I went ahead and grabbed the old binaries from archive.org, created tags
for the releases of jack2 for windows and OSX on the repository of the
homepage and attached the files to these tags. I updated the links on
the page, did some additional maintenance and requested the changes to
be pulled to the webspace on the jack-devel list. That was intended to
be an intermediate solution but you may have already guessed that one
part of my mistake: There is a saying, that intermediate solutions are
the ones that will never go away, so sad, so true. Second, attaching the
binaries to the repo of the webpage confused a lot of people since
normally the tag would have been attached to a commit of the jack2
repository. When a tag is created, GitHub automatically creates a source
tarball and zip for the respective commit, so that a developer only has
to attach the release binaries. I could no do this, since a have no
access to the jack2 repository. The problem is, that users do not expect
to find the releases attached to the repository of the homepage and
also, if you take a look at these tags , you will notice that they
have the source tarballs of the homepage attached where a user would
normally expect the source tarball of jack2.
It's a mess right now more so because shortly afterwards I received a
release of the new installer for OSX and Windows and now there is
another release that uses this suboptimal solution and the old page on
the webspace still has the DropBox links. I updatetd the links on the
page in the GitHub repo accordingly, hoping that people would search for
the binaries on the page after it was (supposed to be) pulled, requested
the changes to be pulled to the webspace... that was half a month ago
and there was apparently no pull.
So that's how we ended up with broken dropbox links on the webspace
(jackaudio.org), two* versions of the page (jackaudio. org and ) and
a whole lot of confusion and frustration about source tarballs
containing strange markdown files and not the jack2 source code.
The technical problems are actually not that hard to solve, but a think
wen have an organizational problem here.
There will be a follow up (good news) to this mail where I propose some
ways to clear this mess and how to avoid it in the future, it may be a
base for discussion and LAC should be a good opportunity to get this
sorted out since the most important decision makers will be there.
* To be more correct and as a very observant user mentioned, there are
three versions since the gh-pages branch of the repo also gets special
treatment (see GitHub pages docs for details) but that is not that much
relevant for this topic.
PS: It's already 1 AM and I am still *jacked* and *pun*ching
Jack-Devel mailing list
|Free forum by Nabble||Edit this page|