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
