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