Jacek,
> - sticky point: dependency on Eigen
As dependencies go, it's pretty minimal. (As long as they don't
start actually depending on cmake.)
> - Serge has Eigen "emulator"
Hmm. Is this worth the maintenance and potential portability
issues?
> - Eigen sufficient for what we want right now,
> but if we want to get fancier with geometry,
> Eigen will become less useful
> - non elegant solution: if Eigen changes infrequently,
> perhaps just copy the header file over to our repo?
It's not just one header, is it? This sounds really bad for a
number of reasons.
> - decision: existing Eigen emulator probably covers what
> is needed for Qserv, so continue with it for now, if
> we discover more work is needed, reconsider and possibly
> switch to using Eigen, in which case the dependency issue
> wouldn't be a problem any more for Qserv. If we stick with
> Eigen emulator, discuss w/Mario/Robert/Jim/KT
I don't understand why there's an "If" in the last sentence
given the decision in the first sentence.
> Using jira
> - will try doing weekly sprints, defined each week at our meeting
You will need to set up a separate Qserv agile board, then, so
you can have your own sprints.
> - integrating with stash - Daniel volunteers to help if it
> makes sense (e.g. lack of appropriate privileges might
> make it too-difficult-to-be-worth-doing by him)
I think this can be arranged with Iain and Mario, but my
impression was that the main stumbling block was getting an actual
machine to use as the official platform.
> - many "empty" emails generated by jira, probably due to
> temporary misconfiguration
I haven't noticed any problems, but then again I get text
E-mails.
--
Kian-Tat Lim, LSST Data Management, [log in to unmask]
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1
|