Re: Proposal: moving tests to GitHub

Tobie Langel wrote:
> Odin wrote:
>> Ms2ger proposed merging our repository with HTML at the same time and  
>> not
>> necessarily having one repository for each group. I was already thinking
>> such a move might be beneficial to do for webapps and webappsec, but it
>> might be even more simple to also have html testsuite in that merge.
>
> There are benefits to both approaches. I would be in favor of having a
> repository per spec (named tr_shortname-testsuite). This will make it a
> lot easier to securely give scoped commit rights to external contributors
> when the need arises.

I'm not really sure if that is needed. If we can trust someone in one  
repository, why not in all?

Having one repository also makes that one more visible, and if you already  
have a checkout for fixing CORS tests, and then suddenly encounter an SSE  
error, you can easily write that test in the checkout you already have.  I  
think the best people we can optimize for is the people who have already  
written some tests.  If it's easy for them to spread out, then we'll get  
more tests.

The visibility might also help, person X forks the test repo in order to  
fix a test in Microdata.  Any linking or talking she'll do about that fix  
will point people to that repo.  If people are like me, they might  
normally poke around a bit in the tree and suddenly they'll also know  
where the tests for e.g. XMLHttpRequest is at.


But what wins me over, is really the overhead question. Do anyone really  
want to manage lots of repositories?  And for what reason?  Also, we want  
more reviewers.  If I'm already added for CORS, I could help out for say  
XMLHttpRequest if there's a submission/pull request languishing there.

Anyway, for my part, the how-to-split repository issue is not that  
important compared to having the tests at GitHub in the first place :-)

-- 
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com

Received on Tuesday, 22 January 2013 12:28:39 UTC