On 2013-08-12 at 07:37:52 +0200, Jason Dagit wrote: > On Wed, Aug 7, 2013 at 11:58 AM, Herbert Valerio Riedel <[email protected]> wrote:
[...] > Is "git" the name we're going to want to keep indefinitely for this? > Once you create a URL (and consequently a domain name) it's nice to > keep it around so that anyone using it can still use it. Even if that > means keeping the (sub)domain for years. Perhaps a more generic name > would be more suitable, for example "scm" (for source code > management)? If we use something that is tool/technology specific then > we need to update the (sub)domain when the tool/technology changes, > lest we sound silly. The problem is, that each tool/technology might require a new namespace. For instance, that http://darcs.haskell.org/ started serving Darcs + Git in the same namespace makes it difficult to offer smart http Git transport, as you'd need to define non-trivial regexps to route smart Git/http accesses to the git-http-backend CGI. Also, the HTTP URLs for Git repos and their original Darcs repos conflict (the ".git" suffix is often deemed optional for Git urls, but currently we *have* to require the ".git" suffix in order to disambiguate). Also, it's useful to be able to create a new namespace, and setup the new tool up there, keep the old tool on the old namespace running in parallel, perform a smooth transition, and let the old namespace phase-out (or keep as archive). Also, having different DNS names for different tools/technologies makes it easier to move it to a separate VM instance. E.g. http://darcs.haskell.org/ can be moved easily to its own VM some time in the future to keep Darcs hosting separate from the Trac/Git services[2]. The naming "http://git.haskell.org/"; follows a common tradition/scheme for naming the hostnames offering Git related services (just a couple of examples I could think of right off the top of my head): - http://git.kernel.org/ - http://git.freedesktop.org/ - http://git.zx2c4.com/ - http://git.gnome.org/ - http://git.debian.org/ - http://git.eclipse.org/ - http://git.apache.org/ - ... Maybe this is caused by books such as Pro Git suggesting[1] such hostnames: | Now that you have a bare copy of your repository, all you need to do | is put it on a server and set up your protocols. Let’s say you’ve set | up a server called git.example.com that you have SSH access to, and | you want to store all your Git repositories under the /opt/git | directory. You can set up your new repository by copying your bare | repository over: ...and moreover, allows uniform/compact Git URLs; e.g. the following 3 URLs only differ by their prefix (and the ".git" suffix is optional btw!): - ssh://[email protected]/ghc.git - http://git.haskell.org/ghc.git - git://git.haskell.org/ghc.git IMHO, this makes it easier for users to remember/type the Git URLs. > Will GHC's source be the only repository? I think we should only do > our own hosting when it's necessary. When GHC switched to darcs, > hosting services didn't support darcs so it was necessary to roll our > own. Now that there are good free git-based hosting services (github, > bitbucket, sourceforge, and probably others), is there a reason GHC > can't use an existing service? This is a very good question. If the GHC project wishes to continue using Trac, then local Git repositories are needed anyway for the Trac/Git integration to work properly. Using our own Git hosting, allows us more customization possibilities as are available in 3rd party hosting services, which usually don't allow to run custom hook scripts on their servers (last time I checked, GitHub doesn't even allow to enable pre-receive tab/whitespace validations). With the new Gitolite setup, it has become easy to add new users/repos and define access-control rules w/o even needing to log into a shell account. This of course doesn't mean that we need to make use of it; therefore, your question as to which repositories should be hosted on git.haskell.org remains open. > If GHC really needs a homegrown service, who is volunteering to keep > it running smoothly and for how long? What is the plan for phasing it > out once it's no longer needed or the maintainer disappears? If it wasn't clear so far, I'm volunteering to help keep the Git/Trac infrastructure up and running as long as I am able to. Ideally, there should be two people in different time zones for each administrative component anyway, in order to have a fallback in case of short-term unavailability (sleep, vacation, illness, ...). > I have access to the haskell.org DNS account to be able to add the > domain, but I would prefer to delegate to one of our volunteer > sysadmins. Hence, I've CC'd the haskell-infrastructure list. Who wants > to be in-charge of the ghc.haskell.org domain? If nobody else offers, I'd gladly volunteer for that. Again, there should be two admins for this as well, IMHO. Cheers, hvr [1] http://git-scm.com/book/en/Git-on-the-Server-Getting-Git-on-a-Server [2] (btw, http://darcs.haskell.org/nhc98 has one active maintainer which prefers Darcs over Git, but Darcs doesn't have something like Gitolite which makes it easy to manage users/access-rules) _______________________________________________ haskell-infrastructure mailing list [email protected] http://community.galois.com/mailman/listinfo/haskell-infrastructure
