W3C home > Mailing lists > Public > public-aria-editors@w3.org > October 2016

Re: Options for maintaining common resources across repositories

From: Ivan Herman <ivan@w3.org>
Date: Thu, 20 Oct 2016 07:33:07 +0800
Cc: ARIA Editors <public-aria-editors@w3.org>
Message-Id: <80368045-2466-441E-8D13-44D4083241BB@w3.org>
To: Michael Cooper <cooper@w3.org>

> On 20 Oct 2016, at 00:04, Michael Cooper <cooper@w3.org> wrote:
> So far the repositories I've split from ARIA are using the common files by referencing rawgit versions. This is not a good strategy; it's not working in the github.io versions (presumably because of cross-domain security restrictions), won't work in w3.org either without manual editing, and is kinda clunky. I've brainstormed a few ways to address this, each with pros and cons:
> Split the common files into a standalone repository and make it a submodule of the other repositories
> Pro - this is probably the "official" way to deal with dependencies of this sort, and allows them to managed independently
> Con - we'd probably have to create a separate repository just for the common files; I'm not sure if Github can update dependencies from submodules without some extra kind of manual kick
> Add some script to change the URIs of common resources, to appropriate to the particular publication location
> Pro - minimal change to our current setup
> Con - have to write the script and have a copy in each repo

FWIW: I had such a script for the CSVW Working group:

https://github.com/w3c/csvw/blob/gh-pages/replace-ed-uris.js <https://github.com/w3c/csvw/blob/gh-pages/replace-ed-uris.js>

although that WG used one repo for several documents, we had a similar problem. I think the same script would work over several repos; it just uses a separate js file that lists the document URI-s themselves. There is a short documentation at the start of the script.


> Add the main repository as a secondary "remote"
> Pro - easier to keep the common files up to date
> Con - not sure this works cleanly unless we still separate the common files into a separate repo, any editor could make changes that impact all the editors
> Fork the common files into versions for each repository
> Pro - easiest path, and can evolve to suit each repo
> Con - they're forked and may diverge, so we lose benefit of shared effort

Ivan Herman, W3C
Digital Publishing Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

Received on Wednesday, 19 October 2016 23:33:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:59:17 UTC