Hi Ray, That sounds reasonable as a starting point. This is a fairly important decision (the repository structure) with implications beyond DC1 and we need to think it through carefully. I would like to task Russ, Robyn, Tim, Robert Lupton, and an NCSA person of your choosing to form a small working group for a longer term plan.
I think the plan needs to incorporate the following objectives: 1. A clear structure allowing builds of individual pipelines as well as complete data challenges/releases of multiple pipelines. 2. Clean separation of "prototype codes" that are clearly throw-aways from "production codes". I realize that we will have little of the latter for some time, but the structure should be able to support it when we do. 3. Mirroring of the repository at multiple locations and remote access from any LSST DM member (with authorization). Secondary objectives would include: 4. The ability to store and version documentation related to the code in a web-viewable form. 5. The ability to store and version design and test artifacts associated with the code. 6. The ability to tag versions/builds with a status indicating completenesss level (development, unit test, integration test, acceptance test). Thanks! Jeff > From: Ray Plante <[EMAIL PROTECTED]> > Reply-To: Ray Plante <[EMAIL PROTECTED]>, LSST Data Management > <[email protected]> > Date: Fri, 2 Jun 2006 04:00:22 -0500 (CDT) > To: LSST Data Management <[email protected]> > Subject: Re: [LSST-data] CVS repository? [DataChallenge] > > Hi Jeff, > > On Thu, 1 Jun 2006, Jeffrey P Kantor wrote: >> I assume we will create a project within the subversion repository specific >> to DC1 and keep the MOPS work in another project. > > As you will see, we were not planning to do this. While I don't expect > this repository to take us to 2013, I was assuming that it's use would > extend beyond DC1, and more to the point, that the software that is part > of DC1 would be developed and used beyond the strict scope of the data > challenges. Thus, I think an organization based on how the software fits > into the data management system makes more sense. > > Nevertheless, there are some practical advantages to segregating out the > DC1 code. One is that a DC1 developer can easily check out just the DC1 > code (and not the MOPS). > > I think the solution to this (but VC experts correct me) is for us to > immediately create a DC1 branch that we check our DC1 code into. DC1 > developers would work exclusively with this branch, while other folks > (link Andy with his MOPS code) just checks stuff into the main branch. > (I think is essentially what you suggested.) When DC1 is over, we simply > copy over the DC1 branch into the main branch. We can potentially do the > same for DC2 and beyond if it still makes sense. Comments? > > cheers, > Ray > > PS: Jeff, I don't think you have a log in at the moment, so here is a > dump of the directories currently in the repository: > > infrastructure > infrastructure/sysadmin > applications > middleware > middleware/archive > middleware/pipeline > middleware/pipeline/management > middleware/pipeline/construction > middleware/pipeline/execution > middleware/pipeline/appframework > middleware/security > middleware/sysadmin > middleware/DAF > middleware/ui > > > > > _______________________________________________ > LSST-data mailing list > [email protected] > http://www.lsstmail.org/mailman/listinfo/lsst-data > _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
