On Thu, May 6, 2010 at 11:02 AM, Tonu Mikk <[log in to unmask]> wrote:
...
> Lastly, I want to mention Google Code
> (http://code.google.com/projecthosting/ ) as a possible way to provide this
> service if Google Code is included with UMN Google Apps offering.  I have
> used Google Code in the past and have had a good experience.

Google Code is not included in the available Apps, but was a good idea
to ask about.

-Jeff Williams

> Tonu
>
> On 5/5/2010 10:35 AM, Christopher Bongaarts wrote:
>>
>> 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?
>>
>