Here are a few supportive thoughts related to the concept of shared source
repositories.
Internal communications: There are certainly University-wide internal
communications reason to explore this further: a source repository would
encourage transparency and collaboration across unit lines. It would help us
share innovative ideas and reduce some of the duplication in coding that we
all know is happening. The institution will need more effective
collaboration as we move into an era of reduced resources. This sort of
sharing also has the potential to help cultural transformation: our
organizational identification will shift, we will all be developing for the
University of Minnesota.

Tonu, I agree that piloting at a smaller level may very well be the
short-term solution. The ASR web team is planning to set up an instance of
Gitorious on a virtual server to help us in managing our codebase.  We are
interested in chatting with other units about our plans. If we find a some
units interested in sharing our repository instance, for example, we could
be lithe, learn about requirements by trying, develop standards for shared
use, and then demonstrate the value as interest grows. Were this pilot
effort successful, we would be able to define our needs more clearly,
provide an example for review, and, to quote Tonu, "Then OIT might be more
willing to centralize the service offering."

Yours,
Santiago

On Thu, May 6, 2010 at 11:02 AM, Tonu Mikk <[log in to unmask]> wrote:

> There are many good ideas brought fourth in this discussion.  Let me add
> some more and continue the conversation.
>
> First, I very much support the idea of a central repository for sharing
> code even though I have not used a version control system before.  The value
> that it would would provide to me would be an ability to look at someone
> else's code and see if it could be used for something that I am working on.
>  This repository to me would be of most value, if much of the code is shared
> freely.  Ideally, I see everyone with the UMN ID having read and download
> rights and project owners deciding who has commit and change rights.  In
> this sense it would act similar to UMN AD group policies where I am able to
> see everyone's group policies and learn from how they have been created.
>
> Second point I want to make is that OIT may not be the only organization
> that may be willing to undertake such a project.  Colleges and units around
> the university that already have an infrastructure in place may choose to
> open it up for University wide use.  When the project becomes large enough
> and the value to the University of demonstrated, OIT may be more willing to
> centralize the service offering.  This kind of a "grounds up" approach would
> help clarify the requirements over time as they are gathered from the
> practice of providing the service.
>
> 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.
>
> 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?
>>
>>


-- 
Santiago Fernández-Giménez
information architect / web project manager
Academic Support Resources
University of Minnesota - Twin Cities

[log in to unmask]
612-625-6423

Steering Committee Member,
Project and Change Management Collaborators http://pcmc.umn.edu