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

Re: ARIA common files approach

From: Michael Cooper <cooper@w3.org>
Date: Wed, 7 Dec 2016 18:39:27 -0500
To: Rich Schwerdtfeger <richschwer@gmail.com>
Cc: ARIA Editors <public-aria-editors@w3.org>
Message-ID: <5ed99042-d03d-80ca-cb11-bd3e67abfe87@w3.org>
On 07/12/2016 4:03 PM, Rich Schwerdtfeger wrote:
> Who will control common
Whomever we want. As it will now be in a standalone repository, we can 
have as many or as few people committing to it as seems useful. We 
coordinate this amongst the ARIA editors.
> and what is the update process if needed?
Plan A is there would be a Travis-CI script that updates all the forks 
whenever a commit is pushed to the aria-common repository. If for some 
reason that runs into problems, there would be a simple procedure that 
we could train a couple editors on.

> Sent from my iPhone
> On Dec 7, 2016, at 2:38 PM, Michael Cooper <cooper@w3.org 
> <mailto:cooper@w3.org>> wrote:
>> In today's ARIA Editors call we discussed the ongoing issue with 
>> handling the common resources when splitting the ARIA repository:
>> https://www.w3.org/2016/12/07-aria-editors-minutes.html#item03
>> Given intractable problems with getting submodules to work with 
>> rawgit, and the need for that feature to work, we revisited forking. 
>> The proposal now is to:
>>  1. Put the common files in their own repository (aria-common) as
>>     previously planned;
>>  2. Put copies of the files (forks) in each of the ARIA repositories
>>     after we split;
>>  3. Set up a commit hook that updates each of the forks whenever an
>>     update is pushed to aria-common;
>>  4. Document that people should not edit the aria-common forks in repos.
>> This isn't the theoretically right way to use git but is practical 
>> and achievable, and unblocks the repository split project. We wanted 
>> to run the thought past the rest of the editors to see about thoughts 
>> before making a firm decision to implement.
>> Thoughts?
>> Michael
Received on Wednesday, 7 December 2016 23:39:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 December 2016 23:39:31 UTC