Hi Andy,

Some of DM-622 comments where more documentation-oriented than configuration-oriented, that's I propose to adress them here. In addition I've migrated the documentation to reST format, html output is available here :
http://lsst-web.ncsa.illinois.edu/~fjammes/qserv-doc/

Have a nice day,

Fabrice

Andy,

Please note that configuration procedure documented in README.txt, refers to the DM-622 one, so it's not consistent with DM-930 code which is issued from current master tip (for DM-930 please use previous configuration procedure).

I don't think it's worth changin it as DM-622 merge will soon solve this minor issue.

Cheers

Hi Fabrice,

here are few things that I think worth mentioning:

• If we migrate docs to reStructuredtext (or some other markdown-like format) should this apply to all text files, is it worth to include KNOWN-ISSUES.txt and RELEASE-NOTES.txt into this migration? I guess main utility of that would be publishing on web site or in github-like setup. Do we have an idea what do we want to do in that respect?
• My biggest issue is with dependencies. I do not think it's a good idea to include the list of dependencies into README-devel.rst, we'll end up with two lists that need to be maintained (one in ups/qserv.table and another in README-devel.rst). There should be only one list so there is no risk of inconsistent package names or version numbers. Until eups provides us a way to install package dependencies only (if that ever happens) can we do something simple just for ourselves like a small script which parses qserv.table and uses eups to install dependencies?
• I am a bit confused by two distribution servers in README-devel when installing dependencies. When you install qserv with "eups distrib install qserv -r http://lsst-web.ncsa.illinois.edu/~fjammes/qserv" do dependencies also come from two servers, how is that handled? Does your private server redirects to http://sw.lsstcorp.org/eupspkg for some packages or is it handled by eups itself?
• admin/tools/qserv-install.sh script still uses scons in admin directory instead of running qserv-confgiure.py, should it be changed as well?
• I was burned once by eupspkg doing unpredictable things (I try hard to avoid using it so there may be more interesting things that I miss about it), it may be worth adding small note to README-devel cautioning developers (below "setup qserv $VERSION"), something along the lines:

  Be advised that eupspkg may generate different version numbers depending on whether the code has changed after checkout. For example it may generate version which looks like "master-g86a30ec72a" for freshly checked-out code but if you change anything in your repository it will generate new version "master-g86a30ec72a-dirty". You may end up with two versions of qserv installed, be very careful and remember to run "setup qserv" with the correct version number.

• If we migrate docs to reStructuredtext (or some other markdown-like format) should this apply to all text files, is it worth to include KNOWN-ISSUES.txt and RELEASE-NOTES.txt into this migration? I guess main utility of that would be publishing on web site or in github-like setup. Do we have an idea what do we want to do in that respect?

Not for the moment sorry, this will be adressed in DM-649.

• My biggest issue is with dependencies. I do not think it's a good idea to include the list of dependencies into README-devel.rst, we'll end up with two lists that need to be maintained (one in ups/qserv.table and another in README-devel.rst). There should be only one list so there is no risk of inconsistent package names or version numbers. Until eups provides us a way to install package dependencies only (if that ever happens) can we do something simple just for ourselves like a small script which parses qserv.table and uses eups to install dependencies?

Both of this solution are weak : indeed they don't contain information about version of each dependency. So the last version of each dependency will be installed, and this may be inconsistent with Qserv version of user git repos,and prevent Qserv build. I think the ideal solution would be to have an eups command like that :

eups distrib install qserv $VERSION --deps-only

As discussed with Daniel on the 07/02/2014, the Qserv dependencies don't move a lot, so maybe we can keep this imperfect solution which will satisfy 90% of our needs, and hope a a eups future feature which will cover this ?

• I am a bit confused by two distribution servers in README-devel when installing dependencies. When you install qserv with "eups distrib install qserv -r http://lsst-web.ncsa.illinois.edu/~fjammes/qserv" do dependencies also come from two servers, how is that handled? Does your private server redirects to http://sw.lsstcorp.org/eupspkg for some packages or is it handled by eups itself?

This is handled by eups itself, I suppose that when a dependency package (example boost) isn't found in http://lsst-web.ncsa.illinois.edu/~fjammes/qserv, eups falls back on $EUPS_PKGROOT (i.e. http://sw.lsstcorp.org/eupspkg).

• admin/tools/qserv-install.sh script still uses scons in admin directory instead of running qserv-confgiure.py, should it be changed as well?

Done in DM-622, current ticket was created from master branch, as recommended, and only adress READMEs files.

• I was burned once by eupspkg doing unpredictable things (I try hard to avoid using it so there may be more interesting things that I miss about it), it may be worth adding small note to README-devel cautioning developers (below "setup qserv $VERSION"), something along the lines:...

I think that this should be done in eups documentation, and not in Qserv one, in order to avoid redundancy and ease maintenance. When eups doc will be up to date, we could provide a pointer in Qserv one.

Cheers,

Discussed during Dev Hangout between A. Salnikov and F. Jammes on Tue July 8, 8:30am-10:30am CEST :

• write a qserv.table parser to generate eups distrib install commands

• Point "I am a bit confused by two distribution servers in README-devel when installing dependencies. When you install qserv with "eups distrib install qserv -r http://lsst-web.ncsa.illinois.edu/~fjammes/qserv" do dependencies also come from two servers, how is that handled? Does your private server redirects to http://sw.lsstcorp.org/eupspkg for some packages or is it handled by eups itself" is solved by previous feature.

• update the documentation (README-devel.rst) with :
  "Be advised that eupspkg may generate different version numbers depending on whether the code has changed after checkout. For example it may generate version which looks like "master-g86a30ec72a" for freshly checked-out code but if you change anything in your repository it will generate new version "master-g86a30ec72a-dirty". You may end up with two versions of qserv installed, be very careful and remember to run "setup qserv" with the correct version number."

• "-a" option : add it in the README file

Please don't write an eups table parser.

1) Ask the eups experts if there is a way to do what you want (install the dependencies of a package you have git-cloned the source for).
2) Ask the eups experts to add this feature if it is not present.
3) Use the code already within eups to parse eups table files and generate install commands if they can't add this feature and don't want to tell you how to add it.

Hello K.T.,

After a few investigations, i realized this feature wasn't present in eups. That's why i implement a first proposal and send a pull request to Robert (first tests are successfull) :
https://github.com/RobertLuptonTheGood/eups/pull/19

All others review request are done, and the ticket is ready to merge.
Andy could you please complete the review ?

Thanks and have a nice day,

Fabrice

P.S. : please note that "eups distrib install --onlydepend" won't be available until it is packaged in eups stable release. For now, you have to install eups from master tip to test it.

K.T. learn us that newinstall.sh now use eups v1.5.0 which supports "eups distrib install --onlydepend" option.

Andy, could you please mark this ticket as done. Furthermore, this would allows to integrate your remarks in master branch, and then rebasing DM-649 on master tip would solve your DM-649 remark :

My old comment still applies - developer setup should not need qserv installed already, I guess this is just waiting for new eups version which will allow us to install dependencies.

Thanks