Glad to see that there's such strong desire for this, because I had
already started promoting the idea as something that may be in the best
interests of the Libraries. When I proposed it to John Butler, UMN
Librarian for IT, he explained that the Libraries and OIT have been
talking about collaborating on some projects, and that a central source
code control system may be a good candidate.

Twice now I've implemented Subversion to use X.500 Central Auth for
authentication, once when I worked in OIT, and now again at the
Libraries, both times with the cooperation of Chris Bongaarts and his
colleague, Mike Hedman.

As Chris suggested earlier in this thread, such a service may not
provide much value in competition with cloud services, for releasing open
source code. If there's enough code that we want to keep private to the
U, though, and enough interest in sharing it, a system that integrates
with Central Auth could be very useful and conveient.  I've found it
much easier to manage users when I can use their X.500 IDs: no worries
about their passwords or revoking access when they leave the U, for
example.

So I'd be very interested in contributing to this effort. I'm also
interested in using Git, possibly instead of Subversion. We're doing a
lot of work with Drupal in the Libraries, and Drupal is yet another in a
long list of projects to switch to Git. Plus I just think Git is
much-better designed and more powerful.

David

--
David Naughton
Web Development, EthicShare.org
University of Minnesota Libraries
[log in to unmask]
5-0473

On Mon, May 10, 2010 at 09:29:47AM -0500, Santiago Fernandez-Gimenez wrote:
> 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