On 02/02/2013 12:50 AM, Tobie Langel wrote:
On 2/1/13 4:23 AM, "Arthur Barstow" <art.bars...@nokia.com> wrote:
One of things I wondering about is - after you leave your Fellow
position [BTW, that's totally wicked so congrats on that!], and Robin
has moved on to `greener pastures` and Odin has moved on to be CEO of
Opera - if/when there are problems with GH, who are we gonna' call? Hg,
despite its shortcomings, is backed by the W3C's crack SysTeam. Do we
get an equivalent service from GH?
In the broader context, git[hub] is very much the low-risk alternative.
Whilst there are certainly people using mercurial, git is far more
popular. Git skills are far more common in the marketplace, and far more
common amongst people who are likely to join working groups. In addition
the tooling support for git is much better; even Microsoft are adding
git support to their tools these days ;) These things have a very real
impact on us. For example I spent some time searching for a code review
tool we could use with hg and came up blank. With git[hub] we get a
mediocre one for free and the possibility of using a very good one once
I add github API support.
If crowd-sourcing is part of our strategy to get more tests, (and the
testing meeting we had this week seems to imply it is), then moving to
GitHub is a requirement.
Yes, those are good points and I'm wondering if there really needs to be
a binary choice here or if there could be advantages to using both. For
example, set up a skeleton structure on GH and if/when tests are
submitted, the Test Facilitator could review them and copy the `good
ones` to Hg.
I have very large doubts about strategies that involve hum a intervention
to sync resources across different versioning systems.
Yes. Having only a skeleton setup on github would mean that people using
that would be unable to fix existing tests. If a file changed on github
that had already been copied across to hg, it would be an enormous pain
to work out whether it is safe to port the changes. I think you would
have to use a write/copy/delete workflow, which would be confusing as
people wouldn't be able to find their contributions.
Having fully repositories in both places is also fairly painful, but
tolerable if the commits are in on place only (if you start allowing
commits in both places, you can end up with a very difficult
synchronisation problem).
