May 2010


Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Tonu Mikk <[log in to unmask]>
Reply To:
UofMN CSS Web Development <[log in to unmask]>
Thu, 6 May 2010 11:02:56 -0500
text/plain (98 lines)
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.


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?