Jacek has been working on packaging 'log' which is the code written by Bill. Bill recently finished working at slac so Jacek is finishing it up.
K-T offered, since this is the package to replace MW pex_logging, to standby for phone consultation.
Jacek noted that, in general, the team is slower than usual due to a mixture of vacation and sick leave.
K-T
The MW sprint is finishing up. Waiting for Greg to close out some JIRA issues that he's actually completed but hasn't marked as such. They made some very good progress.
They have actual simulation of how Nightly Computing is really going to work.
K-T showed Steve's video to Gregory and Gregory seemed happy with that.
K-T said they now have something to work with and experiment with in the future. It's been a very good accomplishment.
K-T continues to help out wherever he is needed as well as get other work done, for example, on Operations and the SAT.
K-T offered to assist Robyn on the Release if new problems crop up.
Robyn
The Release was put temporarily on hold due to a very large commit which 'broke' the stack. Both Perry and Jim are working on it.
K-T: Rolling back is too difficult?
Robyn: Jim said that in its state now, rolling back is too difficult.
Robyn: We need to get the developers to use the ticket build concept. It takes 4 steps. It's not hard:
Enter the generic login of 'everyman' (required)
Enter your email address (required, to get personal status report)
Enter your ticket branches to test integration with the rest of the stack (optional)
Press 'Force Build'
K-T: There's that; but we should also be able to Release anything previously built by buildbot. So we should look into capability, too.
Robyn: I agree. However, the current set of tools currently looks at the existing build stack. It is anchored to the current state of the build directory but there is no real reason that it needs to be anchored. We might have to set aside a few more details when a build occurs; but there's no problem doing that. However, now is not the time - while we're trying to get a Release out - to try to rejigger the code. Especially since the code is 'fresh'; it's not been tested in earnest. So, I have not done anything on the Release yet. I hope that the permission that you gave 'lsstsw' to update the git repos will allow me to move past the first step of git-tagging the packages.
Robyn asked K-T and Jacek - what is our policy for including 3rd party packages in the Release. Those that are included need to have their Copyrights embedded within our own LSST Copyright statement. Some of the new 3rd party packages are due to Sims and some due to Qserv. So the question is what is being distributed in our Release? We've moved to asking the users to pre-install some 3rd party packages; how much of that is being done; do those Copyrights get added to the LSST Copyright?
K-T: We should be able to distribute a number of top level products: the LSST stack, Qserv stack and the Sims stack. The latter two may share some packages with the LSST stack but will also have their own unique packages. Each of those Products should say in their Distribution that they have 'x' 3rd party packages and have their Copyright statements. K-T hopes that we can have one generic LSST Copyright statement and one generic repository of all 3rd party Copyrights.
Jacek thinks that we need to have the Copyright included for every 3rd party package which we distribute and rely on.
K-T: It depends on what license it's under but we need to provide access to the source of all those and the sources of all their Copyrights. But do we need to actually put them into some other document or do we just need to point to them?
... lots more discussion...
Robyn explaining that our current Copyright statement embeds the Copyright declarations for all currently distributed 3rd party packages.
Jacek/K-T suggesting we talk to an AURA lawyer to determine if embedding the 3rd party Copyrights in our own declaration is required or whether we could create a directory/repository of all the 3rd party Copyrights and point to it.
K-T suggesting that we go with what we've always done until we get further guidance for either AURA or the LSST Project Office.
Pursuant to this discussion, K-T later emailed additional info which is included below:
> What is the policy for which 3rd party codes are expected to be provided by users? And which are still provided by DM? "System dependencies" are provided by users. "External packages" are provided by DM. There is no bright line test as to which third-party code should fall into which category, but generally ones where we integrate tightly or which are not commonly distributed with an OS would fall into the latter. Some packages that we expect users to already have and to have personalized will fall into the former.
> I know we're moving towards minimalist DM provision of 3rd party tools but we still provide distrib packages (for our use and outsiders).
I wouldn't say we're moving to a minimalist policy. It's just that Python and affiliates are moving because of personalization.
> The question driving this inquiry is determining which of the new QSERV 3rd party tools should be included into our LsstLicenseStatement.txt statement (https://www.lsstcorp.org/LegalNotices/) .
I think the bottom line is that anything we distribute (that you can "eups distrib install") needs to go there.
Dick
Dick started off with two questions:
Robyn: you sent around an email on how to browse Buildbot and use it. Where is it?
Do we need to specify a copyright on our documentation?
K-T: Everything we write is under copyright according to the Bern Convention implicitly. We had footers in Trac which stated our position on document copyright. He doesn't think they have similar footers in the Docushare templates.
Dick: Maybe I'll look into that sometime.
K-T: There have been some requests to copy our documentation. There were some requests from Trac which we directed to use the disclaimer on the bottom of the pages.
Dick: I've also liberally borrowed from the Sloan survey. I annotated at the top of the page that it was extracted from their document but didn't explicitly use quotes in the text since it would interrupt the flow.
He doesn't think there is a restriction there but he will take note of that. He's also been looking into the HSC documentation and there's possibly some value in collaborating. But if there are Copyright issues, they need to be addressed.
Dick finished reviewing some doxygen documentation that Russell wrote on How to Create a Task. Dick feels it's ready for release.
The next task is to gen up an iPython Notebook for some examples.
Dick is still waiting for response to review requests from Simon and Jim.
Andy
Andy reported he did not have too to report. He's been working off-sprint and off-LSST.
K-T: You managed to work around the butler issues?
Andy responded he'd figured out a workaround. He grabbed from the butler reference the path to the file.
K-T: You are allowed in the mapper to look into the butler locations.