Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

Attendees

Discussion items

WhoNotes
Mario
  • Met with the QSERV team on Wednesday to talk over problems they're having with EUPS and the build system they are using.
    • We came out with a list of things that can be improved:  workflows and some things in EUPS that can be improved. We'll monitor the qserv mailing list situation over the next few weeks to make sure that all of that really works as well as it's supposed to.  So we reach a point where EUPS is really helping and they're not feeling like they're wasting time with it.
    • The recipes are being written up and Fabrice is looking into modifying qserv to run out of the source directory, like most LSST Stack packages.
  • Frossie and Mario have been talking about the new releases: 9.3 and 10.0.
    • There is one step which was done manually last time which is tagging of the packages. They do not want to do it manually this time so Frossie is writing up a script for automatic tagging so we have it for the future. Once that is in place then all the pieces to make the Release fully automatic will be in place with the exception of a bit of glue. So making Releases will just be a matter of waiting for Buildbot to finish.  This will let us make a Release every time a sprint ends.
  • Mairo will be away M-W at the Sloan Data Science meeting.
K-T
  • Steve is already starting on the W15 activities.
    • K-T  hasn't actually started a sprint for him but he will.
  • Greg is working under Don's direction. He has epics, as does Steve but both Greg and Steve need to define stories within those epics.
    • Greg is looking at the combination of Docker and Condor and OpenStack and doing whatever seems most interesting in that space.
  • K-T pushed a new prototype of the new Butler
    • It was announced on the Tickets but not to lsst-data because it's pretty ugly code. It gives the direction that butler's going and it actually does run (a little bit) but it's not anywhere near complete. But there is something there now.
    • People can look at it (repository personal/ktlim/daf_butler.git) and comment.
    • K-T is in the process of writing up a document describing all the things that people have asked for and how you'd use the Butler to do that.
  • Additionally K-T has been working on technical operations items. Has an initial draft of the DM portion of the Operations Concept.
    • Mario is supposed to take a look at the Alert Generation and Data Release Production portion.
      • Mario: I can't promise that I'm going to look at that in the next couple of days. Sorry.
Jacek
  • We closed the S14 Tickets and Epic and sprint. We started a new one with Stories defined in it.
    • No major surprises we are just starting everything.
  • Jacek is away M-W at ADASS the coming week.
  • Re hiring: 2 candidates are being considered.
    • Also, Jacek hopes to bring on a student to help with integration tests.
    • In October, FabriceJ is arriving at SLAC for 6 months.
Simon
  • No blockers, finishing off items in their sprint which is closing today.
    • Russell has been looking at C++11 on MacOSx; he had been stuck on unit tests failing.
      • K-T:  Russell seems to be over that problem now.
      • Jim: It remains to be seen if it works for older versions of MacOSx
  • Simon was doing an exercise of going thru Dick's tutorial and it brings up the obvious question: How do we keep these things in correct shape.
    • K-T: The ideal would be to have:
      • the actual executable code;
      • all the text around it be comments; and
      • the whole thing formatted by Sphinx  - or something like that.
      • Then have  it run as part of integration test by buildbot. It will take a ways to get there.
    • Frossie: She was just talking with Dick about the keeping documentation current by having embeddable examples where the example code is pulled in from the repo and is also run as part of the tests. So that you always have confidence that the examples that you have in your code are actually running. This has to go on the ambition pile right now.
    • K-T: All of the examples/ directories in the packages are built right now; we should make sure they continue to be correct but I don't actually want to have stuff that runs unless it's in a test. 
    • Simon: This is an even  higher level than the examples/ in packages. This truly is an end-to-end; made up of many modular pieces.
Jim
  • Perry and Jim are done with all of the work  they wanted to get in before the first 10.x release. It's not all reviewed yet but they have commitments from all their reviewers to get that done by Monday. At that point they would be ready to do a release with the new measurement framework as the default, and the galaxy photometry included.
  • They are supposed to start a new sprint sometime on Monday as well. Jim hopes to meet with Simon sometime today to do some basic planning on how they're going to do that if they are indeed going to work on sprints at the same time. Jim is hoping that one part of that will be cleaning up that board they created a while ago. To use a better label and to remove all of the SUI stuff in it because Jim doesn't think it makes sense to do the same sprint as the SUI team.
  • JIRA is not sending out notifications by email. K-T said that Serge also noticed this.
    • Frossie needs Jim to point her to a specific Ticket that they can bounce.
      • Use: 945 and 1224  - as reported by Serge on list: qserv-fail.
    • Mario and Frossie wonder if the problem is really due to the switch to new mail server a few weeks ago.
      • K-T responds that Jacek is also having problems with his RSS feed which indicates a JIRA mail problem.  But K-T reports he hasn't had problems with his RSS feed.
  • Jim asks whether we have a decision on how to handle bug issues wrt Epics and PMCS. Jim has added some bug fixes to their board but hasn't added them to their Epics but he does work on them and that makes Jeff unhappy. Should he make an Epic just for Bugs?
    • Jeff gave some guidance that  Bug fixing is part of the development process and should go into the estimate for doing something. But Frossie doesn't think that actually reflects fixing a bug in something that has already been released and no longer part of that cycle.
      • K-T said that the nominal baseline now is that you create a Bug Issue. Work on it as normal as part of your board and sprint but it is not included in your Epic.
      • Mario recapped: Fixing Bugs add no value. Basically,  fixing Bugs restores the value we said we already had. So you can not count Bugs as actual work to produce something valuable. That's why Bug fixes are something different; they are basically overhead.
      • Jim: So we count them in Agile but we don't count them in PMCS.
      • Mario: Agreed. If it turns out we are spending 50% of our time fixing Bugs, then we have a major problem to solve. Not to make the auditors happy but to understand why we are making so many bugs.
Dick
  • Regarding the discussion on keeping the tutorials up to date:
    • Dick did an experiment to recast the Software User Guide in Sphinx markup. He got quite a ways into doing that.  It's one thing to document a user interface; it's another write a user-facing document.  The experiment went rather well.
    • One of the side benefits would be to actually keep those scripts associated with the documentation. If that's done, it's conceivable that one could write tests which would actually be runnable to make sure those scripts still work. The biggest issue there is the access to data but Dick thinks that could be arranged. So there are pieces of the solution but they need to be integrated together.
    • Scribe's post-meeting note: After meeting, Dick updated DM-1290: "Re-cast SWUG as Sphinx doc as pathfinder experiment"
  •  Dick recently worked on a new page for the "Software User Guide" named "Productions of Data Products". It's meant to be the DPDR-Lite. The source reference is very technical and is the project baseline document. This is just a version that allows a user to understand: the stack is primarily focused on running productions; what the productions mean; and the definition of products that come out. It doesn't cover all the territory of the DPDR and certainly not in all the detail.
    • He's just about finished with that and would like Mario to look at it when it's done. It's just about ready to be reviewed.
  • Dick is concerned because he's lost track of everything that's being released in 9.3 that wasn't there in 9.2.  If somebody knows that, it would be good to put together some Release Notes.
    • Frossie doesn't know that we have a good method of maintaining top level products release notes ready to go. Ideally we have them ready and when somebody does something significant they add it to the incipient Release Notes.
    • Jacek's group has been maintaining up-to-date Release Notes for the last 3 months for QSERV.
    • This is another situation where a meta-package structure could help us. Perhaps if we had a repo which essentially hosted the Release Notes.
    • K-T suggested that the content could be automatically generated.
    • Frossie is against automated Release Notes (RN) because it should be a higher level abstraction than just bulleted commit notes. The Release Notes should inform the user:  "This is what you get for the pain of upgrading your software."
    • K-T clarifies that he isn't suggesting the commit notes are the sum total of the RN  but that they are a means of providing the core information about what was included.
    • Frossie thinks it's a lot better if the Release Notes are updated in real-time as changes significant to the users are completed.
    • Mario's process for Releases in 2012 and S2013  was to go to Trac, get all the tickets which were fixed, sort them as to being a bug fix or improvement,  pick out the ones which were most important, write up a paragraph on each of these and put out the Release Notes.
  • Dick noted one of the most important things from the point of view of a  RN is whether the installation instructions have changed. Dick suspects they have not for this release but if they have, the instructions need to be updated also.
  • Dick migrated some pages in Trac related to Software Standards. It looked to Dick as though Robyn was taking a really hard look at that which was really good. He doesn't know when that task can be considered done. 
    • K-T promised to look through that also.
    • Robyn said that all she did was to add in the latest SAT and TCT Requirements & Changes. She didn't look over the documents as a whole.
    • Dick wants to know that the realization of the transcribed documents within Confluence is satisfactory since they reflect project controlled documents.
    • Robyn will also review for content.
    • Robyn inquired if we needed to to maintain in perpetuity the old versions of the Standards.
      • After much discussion on why anyone would want old Standards docs, the consensus was that developers should always be using the current approved Standards; the old Standards had no further utility. Mario summarized "We don't want to turn into digital hoarders. Clean the house. Keep the things you're currently using and need; and get rid of the rest."
Frossie
  • Frossie is doing the Release so that she learns how it is done. She hasn't found the time to do it yet so she is going to try to do it tonight (Friday). If she breaks anything, she'll revert back and ask for help from Mario or Robyn. If she can do it, fine. She doesn't intend on calling anyone up with questions at 11pm. 
  • Frossie is going to look at 'that' JIRA ticket today.
    • K-T - what is the timeline for the couple of documents?
    • Frossie is planning on doing them tonight so that we don't live forevermore with 'interim' solutions.
Jim
  • Jim got email from GregoryD-F on the new schedule for the  visualization cross-subsystem  meeting. He wants to know who else is receiving those emails and is planning on contributing?
    • K-T is receiving them but is not sure he is contributing.
    • Mario and Frossie together: What is this about?
    • K-T: This is the Visualization System, the hardware and software standard across the whole project. This is getting together the Camera, OCS, and DM and deciding on what we actually need.
    • Mario: Is this the DS9 or follow-on..?
    • KT: It might touch on DS9 but it's mainly about the how do we really look at full-frame images in as close to real-time as possible.
    • Jim: I though it was about how much all the sub-systems work together for the various visualization needs; or go it alone because they actually have different needs.
    • Frossie: I'm kind of interested in it.
    • Jim: I've always though I was the wrong person to  be in charge of that; I just happen to be the last person who thought about it.
    • K-T: I'm not sure that Gregory has someone from IPAC attending, I'm pretty sure he does - at least a couple. On the DM side a lot of this should be from the SUI side. It's possible that SQuaRE shold get involved with this.
    • Frossie: I'm interested to know what's going on so I'd like to get on the mailing list.
    • K-T: It's lsst-image-visualization@lsstcorp.org.

Action items

  •