You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by Ted Dunning <te...@gmail.com> on 2013/11/04 17:15:46 UTC

Fwd: git status update

This might be interesting to Drill.

---------- Forwarded message ----------
From: Joseph Schaefer <jo...@gmail.com>
Date: Mon, Nov 4, 2013 at 7:15 AM
Subject: git status update
To: members@apache.org


No we don’t have an ED like Eclipse does to toot our horn
about what we’ve done regarding git, but at some point we’ll
blog about our experiences with git and how projects have
taken advantage of our offerings to do innovative things
with their workflows.

Where we were a few years ago: remember Stefano’s rant about
allowing projects to host at github?  That he left in a fit
about where we were headed and how fast we were going there?
Well look at the newly graduated jclouds project to see where
things stand today, or I’m told Deltacloud which has a similar
workflow.  For all intents and purposes those projects are
“hosted” at github they just treat our repo as authoritative
and automate syncs to github themselves instead of using our
hokey cron jobs.  What I’d like to see next is a project that
really takes advantage of gitpubsub to trigger syncs off each
push to our repo so there is as little lag as possible.  Ideally
we could get github to host a svngitpubsub client instead of
these hokey crons and commit-email based sync scripts and that
way everyone would benefit.

Infra I believe has done an excellent job of both timing adoption
around core advances in the git world that we absolutely needed
in order to provide a bare-bones yet enterprise-grade service.
Our initial rollout hinged around http support and we’ve seen that
aspect of git improve to the point to be just as reliable as the
core git protocol support.  At this point the remaining advances
surround projects taking advantage of gitpubsub to facilitate push-
hook triggers of builds and syncs and the like to streamline our
services.  Nobody else has these features and it is unlikely they
will be adopted elsewhere because our goals are not to compete with
other git hosting providers like github, but rather to coordinate
and collaborate with them in the true spirit of Apache.  We have
dodged several bullets which would have sunk our futures into
inferior technologies like creating an alternate universe with
github FI or worse using an open source hosting clone which is
based on poorly designed scripts that we’ve carefully reviewed
and rejected.

Again I realize that we don’t do a good job of publicizing our
offerings and I can’t say that I’m particularly interested in
explaining them to the unwashed masses on the internet who have
never actually dealt with git on an enterprise level themselves.
Hell we still haven’t gotten around to migrating off the git-wip-us
dns name onto git.apache.org proper, but that will come once our
other ducks are lined up around upgrading our svn repos.

Just wanted to let the members know, since this information is
hard to find unless you pay close attention to the infra lists.