Re: CSS test GitHub repo strategy for TestTWF Shenzhen

On Friday, October 4, 2013 at 1:48 PM, Peter Linss wrote:
> The simplest solution here is to simply turn on write access to the CSS WG GitHub repo for the duration of the event (and possibly just leaving it on after). This way the test suite owners can simply merge PRs during the event directly into the GitHub repo and everything will work as expected. I can easily reverse the direction of the Git<->Hg bridge and we just treat the GitHub repo as canonical during the event.
That sounds like a reasonable option. Especially if this became a definitive change and not a temporary one. Rebecca do you have issues with this proposal? If so, please speak up and/or list them on the wiki? 
> After the event, we can manually re-sync the Hg repo to the GitHub repo if there are any issues with the automatic conversion (or if there are any contributions to the Hg repo during the event).

Who is going to be responsible for doing this? Would that be you, Peter?
> I've also been exploring setting up the Gut<->Hg bridge as bi-directional which would let us leave write access on in both places.

Once/If GitHub become the canonical repository, it might be worth looking at which contributors have a preference for using Hg before investing too much time to setup a bi-directional bridge, but that's entirely your call. As long as test developers can use GitHub, I'm not hostile to other options being available.
> As far as using the CSS WG GitHub issue tracker, that's already been turned on.

That's great. 
> There are issues with being able to set milestones due to odd GitHub access restrictions, but those go away when write-access is turned on. I'll deal with synchronizing the issues with the Shepherd data.
> This leaves the CLA issue, but I can work on either modifying the WPT CLA tool to work with the CSSWG repo, or replicating the functionality via our existing tooling prior to the event.
That's a policy/process issue, not a software one. It's also mostly setup on the csswg-tests already[1]. would just need to be better referenced by the README page.  
> The only other issue this would leave open is having contributors submit tests to two repos, although the process would be identical so the burden would be minimal. This unfortunately isn't something we can resolve until such time as we're ready to merge the repositories.

That's an acceptable tradeoff imho.

It looks like we're making progress here. Thanks! 


Received on Friday, 4 October 2013 19:59:07 UTC