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