Time Series Cube DM - IVOA Note

[Tom Donaldson]

Hi Markus,

I agree with the general sentiment that keeping of repository clean would make it easier to use, especially with respect to removing (or maybe just moving) files that are not longer relevant.  I think the guidelines you mention below make sense, but not in all circumstances, so I offer a few counterpoints below.

Thanks,
Tom


On Apr 5, 2017, at 8:28 AM, Markus Demleitner <msdemlei at ari.uni-heidelberg.de<mailto:msdemlei at ari.uni-heidelberg.de>> wrote:

Dear Mark, Dear everyone-else-who-as-stuff-in volute/.../DM,

I got hold of some time series data and would now like to write a
prototype service for these.  I'd like this to spit out something as
close to current drafts, Jiris proposal, SPLAT implemenation, and my
hopes at the same time.  For that, it would be great if I had a
blueprint of the "current upstream idea", as it were.  So,

On Mon, Mar 27, 2017 at 05:38:55PM -0400, CresitelloDittmar, Mark wrote:
I have 'mocked' the resulting model changes and generated some example
files:
 1) chandra event list (real-world cube file)
 2) timeseries example from the Note.. Figures 5, 6, 7
     with added detail about the CoordSys, Frames, etc.

Are these files available now?  If so, where?


But since I just stumbled around in the DM tree in volute, I've
accumulated some additional requests as regards its (particular)
contents.  They come mainly with my user hat on (at least for me, it
is *very* hard to figure out what's what right now), but a little bit
of what's on my head is also coming from me as operator; everything's
much easier for a VCS (and makes more sense) if the amount of binary
data is a low as it can possibly be.

(1) volute is a VCS, so it does versioning by itself.  It would
therefore be great if you just kept the latest version of each
document in there and *not* use version number in file names.  If
people actually want to go back in time, they can use the standard
svn mechanisms (svn log, svn co -r...; yes, with office files there
are no diffs, which is regrettable, but the full files are still
there).  That would already clean up a directory like
http://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/doc/ very nicely.

When we’re creating “official” documents, the process requires the files tracked on ivoa.net<http://ivoa.net> to include version numbers in the names, and I think it makes sense to have the working copies in volute match those official file names.  We could rename the files as they make their way through the process without losing VCS history, but a decent alternative might be to create an ‘archived’ directory where we could move all files that are no longer being edited.  That would keep the working directory clean but allow fairly easy perusal of the document history.


(2) Being a VCS, I think volute should not be polluted by things that
aren't "source" but can be generated from things in volute.  In
particular, I don't think "baked" PDFs should be in there.  They are
almost certain to cause version conflicts, and there's no added value
in having them in a VCS.  And no, putting PDFs into volute don't
really improve any of the issues associated with using docx…

I generally I agree that “baked” files don’t belong in VCS, but I think it’s a legitimate exception when we want the “baked” files to be easily URL accessible.  Some of these PDFs may fall into that category.


(3) It'd be great if there was a top-level readme explaining where
things are supposed to be (there's vo-dml/README.txt that goes a long
way, but how does that relate to the rest of the dm tree?).  Right now,
if I look for, say, the vo-dml of Dataset, where do I go?  Is
http://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/models/ the right
place?  Or
http://volute.g-vo.org/svn/trunk/projects/dm/DatasetMetadata-1.0/model/?
In the latter directory, there's even a zip file -- that in turn
contains a project.conf that says "GENERATED FILE, PLEASE DO NOT
EDIT!!!" [all the bangs included] -- does something like this really
have to be under version control?

(4) Lastly, again since volute is a VCS, it would be great if you
could just delete from trunk the traces of efforts that are pretty
certainly abandoned (e.g., ImageDM, I guess, SpectralDM-2.0 as well).
These things can always be recovered from the history if really
necessary, and if you think they must be visible somewhere in
HEAD, just make a tag containing whatever is going on (e.g.

svn copy http://volute.g-vo.org/svn/trunk/projects/dm/SpectralDM-2.0/ \
http://volute.g-vo.org/svn/tags/DM-attic/SpectralDM-2.0-as-abandoned
svn remove http://volute.g-vo.org/svn/trunk/projects/dm/SpectralDM-2.0/

All of that would really help usability of the dm subtree in volute.

Thanks,

       Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170405/5b8da26e/attachment.html>