Latest thoughts:

 

After more research and discussion, I'm starting to develop a picture of what our development environments might look like.  Two guidelines for my thinking so far:

• As much as possible, the development environment at the codeathon should be the same one used for ongoing development, to minimize migration efforts and maximize project momentum.
• Optimize for speed of setup and ease of maintenance due to current timeline and resource constraints.

 

Please share any thoughts, we'll need to finalize this within the next few days so we can start setting up.  (jhogan, 4/5)

 

Source control:  Subversion via Google Code.

 

Test environments:  Rails, Drupal, Plone, Apache test environments available.  Local server for the codeathon (faster disaster recovery if lightning strikes).  Central hosted server after the codeathon.

 

Issue tracking:  Google Code.

 

Build farms and automation:  None initially -- local builds on developer machines only.

 

Wiki:  PBwiki (probably silver or gold) for now.  A hosted SocialText wiki is probably a good option to migrate to later (we may be able to get one donated).

 

Chat:  We're looking into setting up an LoTV IRC channel.

 

Mailing lists:  Google Groups (integrates with Google Code).

 

Web and file hosting:  Use our existing LoTV web server.

 

Backups:  Google should be reasonably reliable for their stuff.  We need to automate backups for PBwiki, our website, and our test environments.  Should also do something for the source repository to be safe.

 

 

 

Older notes:

 

Network

• Squid proxies would significantly help network bandwidth / response time at both the designathon and codeathon
  • Need to recruit someone to set up the proxy: I can set up squid for you guys --.Chrysta 3/30
• Kick the tires on the MCC network before the event and assess any extra networking needs.
• Make sure we have on-site / on-call support for both events
• Have backup network hardware on hand

 

Individual hardware

• Both the Designathon and the Codeathon will be BYOL (Bring Your Own Laptop) events.
• A few spare laptops will be available at each event.

 

Pre-existing projects

• Projects with their own source repository, test environment, etc. are welcome at the designathon and codeathon.  There is no requirement to use the provided development environment.

 

Source control

• Considering CVS or Subversion.  Decide by 4/4.
  • Subversion seems to be the favorite so far... please post any opinions!
    • svn is a lot better with binaries. if we're going to be using version control at the designathon, also, it would definitely be my preference.
• Host centrally; use the same server during and after the event
• Options for hosting
  • Self-hosted (lotv.org)
  • Sourceforge (availability?)
  • Code.google.com (leaning towards this)
• Reliable backups a must
• Need to make sure clients are available for various platforms
  • Some docs available here:  http://facilities.cs.utexas.edu/htdoc/documentation/cvs_docs.html

 

Event test environments (i.e. sandboxes):

• Run off a local server to facilitate performance and samba functionality
• Post list of versions for key software packages (apache, php, python, drupal, etc.) and solicit feedback
• Create several test environments beforehand
  • Types of test environments to be supported:
  • Basic Apache
  • Drupal
  • Plone
  • Rails
  • Want to see something else here?  Let us know
  • Any other environment needs will most likely need to be handled by project volunteers as opposed to codeathon staff
  • Our sysadmin could use help from people who are proficient in setting up Plone and Rails!
• Each type of test environment should be easily duplicatable in case more are needed
• Need a backup test environment server set up and ready to rock during the event, in case the first one spontaneously combusts

 

Post-event project support:

• Non-LoTV-related projects
  • Provide pointers to common services for open source projects
    • Hosting providers w/shell accounts, etc. for test environments (suggestions anyone?)
    • Collaborative development environments -- sourceforge, code.google.com, collab.net, gforge

• LoTV-related projects
  • Provide a collaborative development environment.
    • Approach
      • Prefer hosted over self-managed
      • Prefer integrated solution over piecemeal
    • Evaluation criteria
      • Hosted solution or self-managed?
      • Source control
      • Test environment (machine w/shell account and sufficient privs)
      • Build automation (ant/gmake)
      • Bug/issue tracking
      • Team communication tools
        • Wiki
        • Mailing lists
        • Forums
        • IRC
      • Webpage and file hosting
    • Options, in current order of preference:
      • code.google.com (hosted.  does it have shell accounts for test envs?)
      • sourceforge.net (hosted; has subversion and shell accounts.  some concerns about stability and usability.)
      • sourceforge enterprise (self-hosted.   get a donated version?)
      • collab.net (self-hosted.  get a donated install?)
      • gforge (self-hosted)
      • trac (self-hosted)
    • Other considerations
      • whurley has contacts at Google, Sourceforge, Collab.net
      • Possibly get something donated since we are a 501c3 -- collab.net or SourceForge enterprise?
      • Careful of using sites like Google, if we leave them late rthey may still dominate search results for a project.

 

Designathon needs

• Wiki should suffice for most purposes
• Source control is a nice-to-have since some people may want to store their designs in a source control tool
  • However -- maybe better to just have everything consolidated in one place on the wiki?

 

Offers for hardware

• Local machines
  • Randy Z. has one machine

  • I can provide some dedicated hardware for the event, be it networking, storage, or server needs, possibly pretty hefty server(s).  If we need more than what I can indiviually provide, I can make inquires with my employeer about some hardware loans as a sponsorship in part.   -Thomas M.

• Hosted servers
  • I can host subversion repositories and provide a moderate amount (5 to 20 25 to 50 Gigabytes) of reliable storage space jay@meangrape.com
• Network hardware
  • Thomas M. (see above)

 

Virtual-Machine based environment(s)? -- cyberchucktx, 3/15

• Pros
  • Could pre-package entire environments/servers
  • Virtual Machines / appliances could instantly be used on multiple hardware platforms
  • Virtual machine instances could be distributed quickly
  • Provides an

• Cons
  • Learning curve for Virtual Machines (not terrible, actually, IMHO)
  • Hardware needs to be a bit beefy to run well (RAM and CPU speeds)
  • Setup time
  • Compatibility issues across various HW platforms (everyone will have their own laptop)
• Overall
  • We discussed this at a meeting this week, and thought that virtual machines might potentially be useful, particularly in the case where a project wants a development environment that can't co-exist on our central environment server (e.g. becuase they need a different version of a key piece of software.)  However I don't think we have extra manpower to devote to this.  If somebody wants to take this on I can hook you up with our event sysadmin.  -- James, 3/28