Hi Ray,
I think the current setup, which does not group the packages under apps
or mw, works well for now. I found the extra apps and mw directories
really annoying under DC1, and am happy to see them gone. I am sure
that we will want to add structure in the future as our code base grows,
and happily that is easily done with svn. The one immediate thing I'd
like to see is some more descriptive names for the middleware packages -
das and dps just don't trigger much in my brain...
Cheers,
Tim
Ray Plante wrote:
Hi Robyn,
On Thu, 30 Nov 2006, Robyn Allsman wrote:
I'm fine with the *build* tree being:
<rootdir>/
<flavors>/
external/<3rd party> where <3rd party> == <prod>-<version>
software/
apps/<package> where <package> == <package>-<eups
version>
mw/<package>
or
<rootdir>/
<flavors>/
external/<3rd party> where <3rd party> == <prod>-<version>
apps/<package> where <package> == <package>-<eups version>
mw/<package>
Either of these are fine, but I was going with the latter.
However, I still think that the SVN repository should be divided
along the
lines of the package boundaries. And each package has its own {tags
branches
trunk (and maybe, ticket)} .
This is still fine, but I think the idea would be that packages would
be grouped according to their role in the DM system as defined in the
UML model. For instance, all pipeline module packages would go under
apps. Some further grouping might be in order; for example, under
mw/das, we could have separate packages for database ingest service,
replication, etc.
Does this make sense?
cheers,
Ray
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
begin:vcard
fn:Tim Axelrod
n:Axelrod;Tim
org:;Large Synoptic Survey Telescope
email;internet:[EMAIL PROTECTED]
title:Data Management Project Scientist
tel;work:520-322-8735
version:2.1
end:vcard
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
