Christian Dinger wrote:

> I couldn't agree more. The ASR web team uses Git (we moved from 
> Subversion a few years ago), but we'd love to see a centralized source 
> code hosting service from OIT. Not only does it make good security 
> sense, but I think it'd also provide a mechanism for inter-departmental 
> collaboration. Just think of things like CAH authentication code and how 
> hard it is sometimes to track down source code and authors to contribute 
> changes/patches.

A central repository doesn't necessarily fix the problem of project 
abandonment, unfortunately.  At least with the CAH stuff the Wiki page 
has been useful for bringing a lot of that together.

> In fact, Gitorious is open-source and free. I think it would be such an 
> quick and easy win for OIT to set up an instance of Gitorious. Then the 
> we the developers could manage our own repositories and access; it would 
> be minimal work for OIT.

Setting up a new centrally-supported application involves quite a bit 
more work than that, of course; you have to define the service offering, 
identify the support/service delivery structure (i.e. who do you call 
when it breaks?), develop policy and procedures for getting (and perhaps 
more importantly removing!) access, set and deploy backup strategy, make 
a disaster recovery plan, documentation/web site, etc.  All this can be 
done pretty quickly and easily if it's scoped to a single department or 
workgroup, and you've got one person probably doing most of all of the 
tasks.  In today's OIT, I count at minimum 6 people involved for the 
variuos tasks I listed, at least half of whom would not be familiar with 
the actual service to be provided.

The first step would be to start thinking about what the requirements 
are for such a service.  Nailing these down is important if you want the 
system to actually meet your needs.  "Integrates with Dreamweaver, 
Eclipse, (other IDEs here)" is one I see already.  I'm guessing someone 
will want to import their existing CVS/SVN/GIT repos, so that would be 
another one.  Someone should start collecting these and refine them into 
a solid set.

Then (to answer Aaron's question), take these and provide them to your 
IT Directors, and ask them to give them to OIT as a recommendation for a 
service to provide.  This seems to be where we're headed as the 
"official" interface for IT governance requests.

Craig also mentioned the UMFoundry project, and that the larger concept 
of having a U-specific developer community (with tools like source 
control as one piece of it) might be appealing.  I had a discussion a 
couple years back with Alex about this, and I was skeptical that having 
a UMN clone of Sourceforge was adding much value.  To his credit, he 
built it, but it appears to have fallen victim to reorganization and 
shifting management priorities.  If someone wants to start a similar 
effort up again, I would encourage you to think about what value you 
would add over the corresponding "cloud" services available today.

For me personally, I would consider putting the mod_cookieauth{,2} code 
into a central repository, primarily to get the benefits of a 
cvsweb-like interface (which I use frequently when tracking down 
problems in various open-source packages to easily navigate source trees 
and diff between arbitrary versions without having to checkout a copy 
locally).  But such a service might not be a good fit for some of our 
more mission-critical and "private" code.  This would make good 
requirements-bait: would the service be intended primarily for "shared" 
code, or also for "private" stuff, and how would access be enforced?

-- 
%%  Christopher A. Bongaarts   %%  [log in to unmask]       %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%