Software Web Presence

This was a copy of an email sent to Mike by Rick. It's now grown into a more complete document.

LCA Software Development Needs

Jake
  • versioning (software & web content, etc.)
Stephen
  • Central repository of analysis codes/scripts, etc. Constantly hunting around. Not necessarily public.
  • Better documentation.
Alexei
  • Preservation via version control.
Dave
  • Verioning and code centralization is key, us and "external" developers (LCA Alum).
  • Documentation. Therefore, we need to write some docs.
  • Maybe we should talk about bugs at meetings.
James
  • Version control. $ENZO_ROOT/amr_src/version.def, $ENZO_ROOT/VERSION (same file).
  • Start using this wiki, share crazy finds.
  • Coding guidelines, standards.
  • Repository for tools/scripts.
Dan
  • Subversion help guides, especially for merging.
  • Easy way to adding documentation, especially for new functionality.
  • Version control over test files/input files.
  • Help with Robert's I/O (maybe some documentation).
Rick
  • Version control policy.
  • Divide up the responsibility.
John
  • Automated emails of commits (can we do for branches?).
  • Codes area in Plone looks crowded.

Intro

I wanted to write up what I tried to describe today, about how to use the Plone portal, the new Trac site, and static web pages in an effective way. You can think of this as a "hybrid" web plan, since it involves a combination of resources. Our motivation is to use each tool for what it's good for: Zeus-MP could probably use static web pages indefinitely, therefore apache; enzo needs a bug tracker and a source browser, hence Trac; the lab needs a public face, we chose Plone; etc.

Some of this I'm already going with, since we've already discussed it, but I wanted to paint the big picture before rearranging everything.

Goals

  • Good information about our codes in the portal (Plone)
  • Code maintainers can easily manage their project page, or area
  • Developers can maintain the documentation within the code

To do this, I'm thinking of two concrete solutions, and one that will be chosen by the code maintainer, be that a person or a group. (The examples are Zeus-MP and enzo.)

Idea 1: Portal List

The first concrete idea is using a Plone product to help organize things in the portal. It provides a central area, with summary information about each project in Plone. I've set it up during the portal rebuild:

http://lca.ucsd.edu/portal/codes

You can this in more action on plone.org: http://plone.org/products

Someone responsible for maintaining the code would update this are with new releases, etc., for their project. But this wouldn't be the "main" web page for a project, except for something small, like maybe a bundle of useful scripts.

FYI - Here are the project listings for the ones I've added:

Zeus-MP http://lca.ucsd.edu/portal/codes/zeus-mp enzo http://lca.ucsd.edu/portal/codes/enzo

Once Jake is back, we'll start filling in.

Idea 2: Static Documentation

By static documentation, I mean flat files that can be generated from the source code, or stored in the version control repository. This way, user (and maybe developer) documentation can be generated nightly, and at releases to be kept on a web server. Like at:

http://lca.ucsd.edu/software/EAL/doc/html OR http://lca.ucsd.edu/software/enzo/amr_guide

I realize this isn't original, all I'm doing is hooking pieces together. For example, the projects in the portal list have documentation links, so that people can get to the user guides. And the project pages can have links to the documentation.

Idea 3: Project Pages/Areas

I think that project owners (groups or individuals), should be given a choice of options for how they want to maintain a web area for their project, along the lines of:

  • Folder in the portal (Plone)
  • Webspace on mngrid (the once and future lca.ucsd.edu)
  • Trac site or other fancy setup on mngrid

This way, the pages for projects like Zeus-MP and MGMPI can be in a central location (i.e., mngrid.ucsd.edu/software), without much effort. And high-maintenance projects (enzo), can have more features to work with users, etc.

In the particular case of the new enzo site, I think we should relax our stance on outside users. I've written it up on the site at: http://mngrid.ucsd.edu/projects/enzo/wiki/PermissionSuggestions Brian asked for these features a while ago--now we have them, and we should use them.

Personal Web Spaces

Along with the project spaces on mngrid, we should open up personal web pages on mngrid. As you said, mngrid is becoming the new cosmos. We should get things moved before cosmos loses another disk or fan. Or, worse, Pete tries to put it back in the lab.

Common Appearance

UCSD does have standards for web pages. They're pretty minimal, but at some point we'll have to take them in to account.

http://www.ucsd.edu/guidelines/web/

Page Locations

After working with John on redirecting users for the Zeus pages, here's a proposed layout for web spaces (All under lca.ucsd.edu):

Old New Description
/ /portal Plone portal
/codes /portal/codes Any software project sites kept in Plone
/codes /software Any software project sites kept in flat html files
/codes /projects Any high-speed, low-drage software project sites like this one
N/A /portal/software Software center, listing of our codes