• Created by Unknown User (robyn), last modified on Aug 10, 2014

Date

Attendees

 

Discussion items

Andy

  • Halfway through his task documentation. Given working on Sat, Sun & Monday, he should have work finished in time.
    • He raised the question as to who might have the time to do the review for the documentation.
    • Simon commented that Robert has said the documentation updates could be made directly to master. K-T concurred - noting that it doesn't need to go through review. But if the author has questions, then ask somebody.  Andy has been having Russell and Simon go over the doc all along. Simon said he could go over he docs again before Monday, if needed.

 

Jacek

 

  • Working on Qserv documentation
  • Continuing migrating Qserv to the new logging. They discovered a few things..for example combining miltiple messages into one message stresm. So they are working on some examples for that.
    • K-T added that if it's really useful to assemble log messages in pieces, it's a relatively simple API to add.
  • They are continuing on hiring. They have found a good candidate that they want to offer the position to.
  • They are also planning for Winter 2015

Jim

  • Jim was in progress of doing a final build of his exceptions ticket before pushing the merge.
  • Next he'll work on more task documentation
  • Then a little bit of refactoring in meas space. There are a lot of very small cleanups in meas space; he thinks it's time to bite the bullet and get them all done. So, he'll do another quick ticket with those today. Mostly just putting the finishing touches in the right places:  fixing trailing white space, fixing formatting issues, and merging some files which should never have been split up.

  • K-T jumped in and commented on a new refinement to the standard workflow which is currently being talked about:
    • Create your issue branch on a u/<user>/DM-####  
    • When you are ready to review:
      • rebase onto master
      • do a buildbot build specifying that issue branch
      • then ask for review
    • When it get's reviewed:  then merge to master.
  • Jim: So when it gets reviewed we're rebasing on top of master now? I wasn't aware of that step.
    • K-T: You can only do that if you're using a 'u/' branch. You can't do it on the DM branches.
    • Simon: I thought we said no. Didn't Mario put that in or not?
    • Jim: No. Even though u/ branches create backups, you still can't force-push to tickets.
  • K-T: That's the way we're talking, is that correct?
    • Jim: Yes, That would solve the problem of not being able to build hybrid stacks of ticket branches and master because your ticket branch is out of date without having to merge master back into the ticket branch.
    • Robyn raised a question: This means that we're supposed to work on u/ branches now?
      • K-T: Yes, this technique has you working on a u/ branch. A lot of people seem to be doing it. I don't know how much we like it. Let's talk about it this coming week and  figure out what we really want to happen.  If we'd rather be able to force-push to ticket branches and then not have all these u/ branches floating around then it's OK. Or if we just want to have everything be u/ branches,  we could do that, too.
    • Simon: Is there any danger to force-pushing to a ticket branch now that the branch is backed-up?
      • K-T: I think the only messy part  is if multiple people are working on a single ticket. Those people can't be working on a u/ branch but it's conceivable that we might have multiple people working on a single ticket.
        • Jim: Yep, Perry and I have certainly done that occasionally. But we've usually gotten around it by creating u/ branches for those tickets that we work on together.

Simon

  • Simon has been working a lot with helping people install the stack for the Cadence meeting next week.
  • He worked with AndyC on the project parameters database.
  • He's been finishing up his task documentation. He should be done with it today.
  • Dick: I understand that you're working on a session for next week relating in part to cameraGeom. Is that right?
    • Simon: Paul and I sharing. a session where I'm going to talk about cameraGeom and he's going to talk about tests. And then Simons' going to be talking in Andy Becker's session on specifically about DecCam cameraGeom.
    • Dick: My hope is that I can harvest a little bit of that information to include in the Confluence page on representations of the camera. It occurs to me there is material which is missing and I'm hoping that you'll  be filling it in. So I'm giving you a head's up that I'd like to get ahold of it when I can.
    • Simon: Russell's writeup didn't fill in what you needed?
    • Dick: Russell's writing up how to create a task in the doxygen documentation - but I was really referring to the cameraGeom and all that. There's not a lot of detail I need but what I was hoping to do was paint a rough picture of : You've got data and you want to make a camera - how do you do that?
    • Simon: OK. The AssembleCCD documentation has an example of how to assemble a detector from scratch. So that might help. We'll talk next week and if don't answer all your questions, we can work from there.
  • Simon inquired of Robyn: I tried to 'distrib install v9_1' but it broke at astrometry_net because of a patch which doesn't exist for Macs. Is that going to be fixed soon?
  • Robyn" Yes that fix is in progress on Mario's laptop right now.
  • K-T: Are you calling that 9_2 or 9_1_1?
  • Robyn: It'll be a surprise.

Dick

  • Dick is working on the first basic tutorial presentation stuff. He wanta to get forward references of what you guys are doing. Not to cover the material but to make them aware of what's coming.
  • The other thing Dick's been doing is checking out Robyn's releases and telling her when they break.
  • Dick made an iPython Notebook to display results of the running of stack demo. This is something to check that the stack installed correctly. All it does is bring up ds9, put 5 colors up in different frames and overplot the detections. Which is good but it requires access to local data so you have to download the iPython notebook  for that to work as best he can tell. He added a caveat that he's not an expert in iPython Notebooks. Dick asks anyone who has more expertise then he to help him understand how he could present that material somewhere - confluence or elsewhere - where it would actually illustrate what he hopes to.
    • Andy: Shoot me an email and I can help you out with this.
    • Dick: That'd be great.

Robyn

  • We should have the the new release soon. It fixes 2 things: the python package which was acquired from master instead of a git-tagged release and the astrometry_net package which went looking for a clang patch which had been removed since it was no longer needed.

K-T

  • Since Tuesday's meeting he spent a whole day with Frossie getting interesting input based on her past experience with telescope control systems and how we seem to be doing things differently than others.
    • Robyn: Was that good or bad?
    • K-T: Well, different. Not necessarily good nor bad. Just something to stay aware of it.
  • Preparing for next week in a bunch of areas:
    • trying to help out with the release
    • getting a bunch of code reviews off his plate
    • had a little time to work on the Butler but the coding is not going very rapidly.
  • K-T asked Jim if he had an ideas about  coverage in swig
    • Jim did not have any suggestion at hand.
    • K-T: The big problem is that there are big chunks of the .i files that we don't care about and it doesn't look as though there is any way to disable reporting on them easily.
    • Jim: And even bigger chunks of all the generated files.
    • K-T: Yes. We'll need to think about that.