Date

Attendees

Discussion items

WhoNotes
Jacek
  • Qserv's Summer2014 work was closed yesterday; it built and tested successfully.
    • Unfortunately after some late night development work, it's now failing during runtime.
    • This only impacts qserv, not the core DM stack needed for Release.
Jim
  • Jim and Perry's last Summer2014 sprint was closed over the weekend.
    • Jim has 4-5 tickets out for review.
    • There are 2 additional tickets which Jim hopes to get out to review today.
  • Perry has one ticket he's working on as well – it's the major refactoring which touches many packages. Correction: this issue (DM-1071) actually fairly limited in scope, but it flips a very important switch that changes which of two coexisting code branches is used by default.
    • Jim thinks the ticket has been totally reviewed.
    • There will be one additional change needed once the core changes are installed - that's the update of the benchmark comparison file used during the processCCD I&T overall stack check.
      • Robyn commented that the usual procedure for updating that file is
        • run the processCCD test;
        • have a domain specialist validate the newly generated output results;
        • replace the old benchmark file with the new results.
        • If the structure of the processCCD input or output data changes, then the processCCD driver needs to be updated  before the validation run.
      • Jim commented that Perry has been monitoring the processCCD output results all along. Jim noted there were some data structures changes which probably require more wholesale update of the driver source and data files.
  • Later in the meeting Jim brought up a package naming change. The meeting's comments have been replaced with his post-meeting email on the subject:
    • To clarify the status of the measurement overhaul w.r.t. these releases: I think we agreed on the stand-up telecon today to delay a few major changes (the switch to meas_base as default, the addition of CModel flux measurements, the removal of meas_extensions_multiShapelet, and the renaming of meas_multifit to meas_modelfit) until *after* the 9.4 release, with the understanding that the first 10.x release (or at least its tagging) would also happen later this week, or very early next.
Simon
  • There are a couple of things Simon would like to finish up before he's ready for tagging. 
    • Simon's waiting on a review from AndyC who said he could do the review tomorrow.
    • It's not a huge problem if Simon doesn't get this last change installed before the Release is cut because even without this last change the software is not broken.
  • Russell has been working on getting a stack built using C++11; he's now moving on to looking at Python 3. I meant SWIG 3 (KSK), He's been having a hard time using the lsstsw tools building on a Mac.
    • Frossie inquired what the motivation is to get the stack built on a 3 year-old OS which is covered by a free-upgrade from the vendor . She made the point that we are in development phase and are supporting alternate OSes on a best effort basis. She's going to inquire of the developer most concerned about the builds on ancient MacOs.
Mario
  • Frossie asked Mario who would/should cut the new Release: Summer14. K-T thought that Frossie would do it but Frossie feels she needs tutoring by Mario in order to do it.  Mario and Frossie decided on 11am Thursday; Mario said it would take about an hour.
    • Putting out a release of the stack boils down to:
      • Find the buildbot tag (b###) for a successful build you like that is going to become the Release;
      • Then run 'publish' on lsstsw.
  • Jim said that he's just about ready to install a major change and would like to have a pre-change Release and a post-change Release. This would foster the DM-stated goal of more frequent Releases.
  • Mario said they could tag the 9.4 (or whatever is the next in line) before Jim's changes; and then after Jim's changes are incorporated, tag the next one 10.x.
  • Mario pointed out that it's not necessary to tell the developers to stop updating 'master'. Once buildbot creates a build that you like, then you can use those SHA1s to tag them.

 

  • Mario is working on budgets.
Dick
  • Dick has migrated the Coding Standards from the Trac wiki to Confluence.
    • He would like them reviewed by someone in the SAT; he made K-T the Jira issue's reviewer.
    • Frossie said to add the SAT component to the relevant JIRA  issue since that's the way to get SAT attention.
Frossie
  • Frossie hooked up buildbot with hipchat last night. If you want to see what's happening, go there. If you have any suggestions, let Frossie know.
    • Mario provided a suggestion regarding toggling a build from hipchat.  The Scribe could not accurately hear the details so talk to Frossie and/or Mario if the following content leaves you unsatisfied.
      • Frossie:  There are plans so that once a commit is pushed, a build would be automatically initiated.
      • Mario: The idea is that the work is done on a branch and when it's ready the developer wants to test it
      • Frossie: The idea is you'll push to a smoke branch and buildbot will automatically pickup from the smoke branch and test it.
      • Mario: Smoke branch?
      • Frossie: It's lingo.
      • Mario: What happens when you have more than one repository with the same branch? That's why we do forced builds the way they are done now.
      • Frossie: We'll work on that. That's part of the whole CI  ...
      • Mario wants to be able to trigger builds from either the web browser or phone.
      • Frossie reminded him that he could currently initiate builds from his web browser - all he needs to do is login.
  • Jacek directed a question to either Frossie or Robyn: Qserv has a new package called qserv-distrib which aggregates the packages qserv and qserv-data.  Who should he contact to get that incorporated into the build stack?
    • Frossie: Open a JIRA ticket assigned to Frossie.

Action items

  •