udaykiran19491/user-stories-from-tawos-for-llm-fine-tuning huggingface dataset:
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The git repository for astrometry_net_data contains a token representation of the CFHT data and the README guidance on acquiring USNOB data.  Neither of these two datasets, as-is, have had recent-past use.   Option 1: This Issue is to resolve whether they should be carried indefinitely in the git repository as they now stand; or  Option 2: Reconsider how we setup, maintain, and programatically access the various astrometry_net_data datasets and then implement the new specification.  Option 3: Perhaps this is an ancillary task to developing a new specification for how we maintain and access the different types of datasets we use: ephemerides  and test data.  The options run from Trivial importance for Option 1, Minor importance for Option 2, and Major importance for the overarching Option 3."
Answer: 2531333.0

User story: In DM-384 and DM-242, we disabled the periods-to-underscores translations for new tables ("version 1") but left it in place for old tables ("version 0").  In addition, when reading a table without a version number, we assumed it was version 0, to maintain backwards compatibility.  I think we should modify this slightly: we should assume a table without a version number is version 0 if and only if it also has the AFW_TYPE key.  Otherwise we should assume it is version 1.  This will allow us to load externally-produced tables without turning any underscores they contain into periods, while still maintaining backwards compatibility with older tables written by afw.
Answer: 185863.0

User story: "We have a worker script that takes three arguments: a CCD number, a cache limit, and a length of time.  The script starts out looking at a slot-specific filesystem for a calibration file /local/slot#/calib/CCD#.  If that file doesn't exist, it checks to see if there are more than the cache limit of files in /local/slot#/calib.  If there are, it removes one at random (later we could try other algorithms).  It then immediately transfers /gpfs/calib/CCD# (maybe a 1 GB file) to /local/slot#/calib/CCD#.  The script then waits for the given length of time and exits.  We make sure we can measure how many file copies from /gpfs are performed and when so that we can determine peak demand rates and average rates.  Meanwhile, the HTCondor hook checks for the same /local/slot#/calib/CCD# files and sets the ClassAds based on which CCD#s are present.  Scenario 1) 4 slots, 4 CCDs, cache limit 1, jobs take 1 min, total of 5 jobs per CCD, 1 job per CCD submitted every 2 min (1234 pause 1234 pause 1234 pause 1234 pause 1234)"
Answer: 14044.0

User story: "This include file was damaged somewhat by the addition of slot routines to work with the flattened field definitions.  It would be nice to put the Measurement abstraction back in place -- or get rid of it.  We need to decide whether the old slot and compound key mechanisms from SourceTable version 0 are going to be continued for doing this.   "
Answer: 394215.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "This story captures the work of investigating the implications of the different options to compensate for Dcr: ignore objects with extreme colors, compensate for Dcr in measurement, and compensate per-image at the per-object/pixel level.  We anticipate the latter option will be required going forward, but we need to do the background work to justify this.  We need to understand exactly which classes will need to make use of Dcr information, and what the limitations are of operating at the per-pixel level (e.g. blends)."
Answer: 48900.0

User story: "Build the OCS Interface  Send all OCS commands Respond to OCS commands"
Answer: 166920.0

User story: "Additional steps for fault tolerance  * Build standby Base DMCS * Build standby Archive DMCS"
Answer: 208540.0

User story: "Add components that aid in fault tolerance of components in the simulator.  * Build replicator/distributor heartbeat/lease * Build replicator and distributor output checks * Build multiple replicator pools"
Answer: 187188.0

User story: "I'd like to be able to run lsst_build without having to specify --exclusion-map and --version-git-repo on the command-line every time.  While I can do that with an alias, I think it should be something built-in.  Ideally, for --exclusion-map, there'd be a search path and some sort of syntax for having higher-priority config locations override lower-priority options.  (As you might have guessed, this will be the first of many feature requests for lsst-build as I try to switch from my own bot tool and find things that seem to be missing)."
Answer: 3414691.0

User story: Need to develop the rationale for the acquisition of Dev and I&T cluster hardware in FY15 and early years. There's some uncertainty as to whether we need a large cluster that early, or should it be deferred to FY16.  Issue opened as a follow-up to personal e-mail discussion with subject "discussions with mario last night". See that thread for some comments/proposals. 
Answer: 1552805.0

User story: "The final stage of moving the old algorithms to meas_base will be to generate the doxygen documentation and be sure that it is useful.  We will do this after the  cleanup of the old meas_algorithms code."
Answer: 167929.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Workers added to the simulator.  Assume: Workers nodes have already in the pool.  Sequence:  * Base DMCS receives nextVisit event * Base DMCS launches worker jobs, one for each CCD (189) and four more for wavefront sensors. * Each worker job launches with visit id, the number of exposures to be taken, a foresight pointing, a filter id, and a CCD id.   * Worker computes the spatial region that covers the expected area of the CCD plus a margin.    * Worker retrieves the template image (by filter and airmass), Objects (from the last Data Release), DiaObjects, past DiaSources, and SSObjects that overlap the region using the Data Access Client Framework.  It also retrieves the master calibration images appropriate for that CCD and filter.  The following two steps are done twice in normal science mode;  there may be other configurations were this is done once, or more than twice. * Worker jobs contact the Archive DMCS via a blocking call to determine the distributor for the image and raft. * Worker jobs contact the distributor (from the previous step) to request the image via a blocking call.  Finally: * Worker jobs send VOEvents"
Answer: 122390.0

User story: "Add Archive DMCS  Demonstrate:  Receiving information from duplicator (visit id, exposure sequence number, raft id, and network address)."
Answer: 50392.0

User story: "Add distributor to the simulator  Demonstrate:  Replicator node associated with to distributor node Replicator jobs send job info to distributor node Replicator jobs copy data to distributor node."
Answer: 41881.0

User story: Change places like {code}#include "cssException.h"{code} to {code}#include "css/cssException.h"{code}   
Answer: 10485.0

User story: According to our coding standard 4.15: https://dev.lsstcorp.org/trac/wiki/C%2B%2BStandard/Files#a4-15.OnlysystemincludefilepathsSHALLbedelimitedwith  we should be using "" for boost, but in quite a few places we do not:  {code} grep 'include <boost' */* |wc      146     314    7916 {code} 
Answer: 228214.0

User story: "Create the Base DMCS and Replicator processes that demonstrate  Send startIntegration Send startReadout  Assume:    Archiver and Alert Production Cluster already enabled, replicators already registered in fully-operational pool.  Demonstrate:  Sending startIntegration event to the Base DMCS. Replicator jobs submission Replicator jobs subscribe to startReadout Sending the startReadout event to the replicator jobs. Replicator jobs receive startReadout Replicator jobs pull data "
Answer: 17369.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: I looked at includes in "core/modules", here is a summary.  * ":" indicates a dependency * global, log, util, wbase, wlog and xrootd are low level, it is an easy, I didn't bother showing them below  * "!!!" indicates circular dependency  * lower-level modules first  {core} css:      <nothing> global:   <nothing> mysql:    <nothing> obsolete: <nothing> proto:    <nothing> sql:      mysql wconfig:  sql, mysql wpublish: sql, wconfig  !!! wsched <--> wcontrol !!! wcontrol <--> wdb wsched:   proto, wcontrol wcontrol: mysql, sql, wsched, wdb, wcontrol, obsolete, proto wdb:      sql, mysql, proto, wconfig, wcontrol  xrdfs:    wpublish, wdb, wconfig, sql, obsolete, wcontrol merger:   sql, xrdfs xrdoss:   obsolete, wpublish, xrdfs  !!! control <--> qdisp !!! qana <--> qproc !!! qana <--> query !!! parser --> query -->qana --> parser !!! query --> qana --> qproc --> query control:  css, merger, obsolete, qdisp, qproc, query qdisp:    control qana:     css, parser, qproc, query qproc:    css, merger, parser, proto, qana, qdisp, query query:    css, qana, qdisp parser:   query {core} 
Answer: 433363.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "I'm seeing something strange when I run scons from current master - running 'scons install' after 'scons build' re-compiles several C++ files even though nothing has changed between these two runs: {code:bash} $ scons build scons: Reading SConscript files ... ... scons: Building targets ... scons: `build' is up to date. scons: done building targets.  $ scons install scons: Reading SConscript files ... ... scons: Building targets ... swig -o build/czar/masterLib_wrap.cc -Ibuild -I/usr/include/python2.6 -python -c++ -Iinclude build/czar/masterLib.i g++ -o build/czar/masterLib_wrap.os -c -g -fPIC -D_FILE_OFFSET_BITS=64 -fPIC -I/u2/<USER>STACK/stack/Linux64/protobuf/2.4.1/include -I/u2/<USER>STACK/stack/Linux64/xrootd/qs5/include/xrootd -I/u2/<USER>STACK/stack/Linux64/mysql/5.1.65/include -Ibuild -I/usr/include/python2.6 build/czar/masterLib_wrap.cc g++ -o build/control/AsyncQueryManager.os -c -g -fPIC -D_FILE_OFFSET_BITS=64 -fPIC -I/u2/<USER>STACK/stack/Linux64/protobuf/2.4.1/include -I/u2/<USER>STACK/stack/Linux64/xrootd/qs5/include/xrootd -I/u2/<USER>STACK/stack/Linux64/mysql/5.1.65/include -Ibuild -I/usr/include/python2.6 build/control/AsyncQueryManager.cc g++ -o build/control/dispatcher.os -c -g -fPIC -D_FILE_OFFSET_BITS=64 -fPIC -I/u2/<USER>STACK/stack/Linux64/protobuf/2.4.1/include -I/u2/<USER>STACK/stack/Linux64/xrootd/qs5/include/xrootd -I/u2/<USER>STACK/stack/Linux64/mysql/5.1.65/include -Ibuild -I/usr/include/python2.6 build/control/dispatcher.cc g++ -o build/control/thread.os -c -g -fPIC -D_FILE_OFFSET_BITS=64 -fPIC -I/u2/<USER>STACK/stack/Linux64/protobuf/2.4.1/include -I/u2/<USER>STACK/stack/Linux64/xrootd/qs5/include/xrootd -I/u2/<USER>STACK/stack/Linux64/mysql/5.1.65/include -Ibuild -I/usr/include/python2.6 build/control/thread.cc g++ -o build/merger/TableMerger.os -c -g -fPIC -D_FILE_OFFSET_BITS=64 -fPIC -I/u2/<USER>STACK/stack/Linux64/protobuf/2.4.1/include -I/u2/<USER>STACK/stack/Linux64/xrootd/qs5/include/xrootd -I/u2/<USER>STACK/stack/Linux64/mysql/5.1.65/include -Ibuild -I/usr/include/python2.6 build/merger/TableMerger.cc scons: `install' is up to date. scons: done building targets. {code}  This is kind of unexpected, or at least I can't understand now why it happens. Trying to run with --debug=explain shows that some dependencies have disappeared and in some dependencies order is different. No clue yet what that means and how it could happen. Need to study our scons scripts to understand what is going on."
Answer: 23189.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The switch to meas_base will involve changing the names of most measurement algorithms, as we're using a new naming convention that provides more traceability.  This will break downstream code that:  - uses field names instead of slots to access measurements  - reads or modifies the list of configured-to-run algorithms.  Whenever possible, we should fix the former by converting them to use slots, as this will automatically provide backwards compatibility.  I'm not yet sure how to handle the latter; the easiest solution would be to give up on full backwards-compatibility with meas_algorithms, but we might be able to find some way to make the old names aliases to the new ones during the deprecation period. "
Answer: 106563.0

User story: "We have a new multi-band processing scheme for coadds on the HSC side, encompassing changes in afw, meas_deblender, and pipe_tasks.  These should be transferred to the LSST side, with RFCs for any backwards incompatible changes.  Changes to the Footprint classes may only be temporary, as we plan to refactor those classes soon anyway, but they're still worth doing now to support the higher-level changes."
Answer: 420782.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Running tests (qserv-testdata.sh) on pre-loaded data I have observed that many test fail for the only reason that the column names in the dumped query results are different between mysql and qserv. Here is an example of query reqult returned from mysql: {code} mysql> SELECT sce.filterName, sce.field, sce.camcol, sce.run FROM Science_Ccd_Exposure AS sce WHERE sce.filterName = 'g' AND sce.field = 670 AND sce.camcol = 2 AND sce.run = 7202; +------------+-------+--------+------+ | filterName | field | camcol | run  | +------------+-------+--------+------+ | g          |   670 |      2 | 7202 | +------------+-------+--------+------+ {code} and this is the same query processed by qserv: {code} mysql> SELECT sce.filterName, sce.field, sce.camcol, sce.run FROM Science_Ccd_Exposure AS sce WHERE sce.filterName = 'g' AND sce.field = 670 AND sce.camcol = 2 AND sce.run = 7202; +----------+----------+----------+----------+ | QS1_PASS | QS2_PASS | QS3_PASS | QS4_PASS | +----------+----------+----------+----------+ | g        |      670 |        2 |     7202 | +----------+----------+----------+----------+ {code}  We discussed this already with Daniel yesterday and at qserv meeting today, here I just want to collect what we know so far so that we can return to this again later.   As Daniel explained to me this is the result of the new parser assigning aliases to the columns which do not define aliases for themselves. This helps with tracking query proceeding through the processing pipeline. Daniel's observation is that different database engines may assign different names to result columns (or some may not even assign any names), there is no standard in that respect so there is no point in trying to follow what one particular implementation does. Additionally there are issues with conflicting column names and names which are complex expressions.  Difference in column names breaks our tests which dump complete results including table header. The tests could be fixed easily, we could just ignore table headers when dumping the data. More interesting issue is that there may be use cases for better compatibility between mysql and qserv including result column naming. In particular standard Python mysql interface allows one to use column names to retrieve values from queiry result. If qserv assigns arbitrary aliases to the columns it may confuse this kind of clients.  This issue depends very much on what kind of API qserv is going to provide to clients. If mysql (wire-level) protocol is going to be the main API (which would allow all kinds of mysql clients to talk to qserv directly) then we should probably think more about compatibility with mysql. OTOH if we decide to provide our own API then this may not be an issue at all (but we still need to fix current test setup which is based on mysql).  We probably should discuss API question at our dev meeting."
Answer: 3130616.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "This is a tracking issue to make sure we upgrade EUPS and that next EUPS release incorporates bugfixes of importance to us:  * https://github.com/RobertLuptonTheGood/eups/issues/14 "
Answer: 449419.0

User story: A query that references non existing column for non-partitioned table results in a confusing message: "read failed for chunk(s): 1234567890".  To repeat, run something like {code} SELECT whatever FROM <existingTable>; {code}  Similar error occurs when we try to reference non-existing table, try something like:  {code} SELECT sce.filterName  FROM StrangeTable AS s,       Science_Ccd_Exposure AS sce  WHERE  (s.scienceCcdExposureId = sce.scienceCcdExposureId); {code} 
Answer: 423326.0

User story: "There is a bunch of (I think) unnecessary translation from KvException to QservAdmException. Can't you just handle printing KvException in CommandParser.receiveCommands(), and get rid of the CSSERR error code? (This is in /admin/bin/qserv-admin.py)  (this came up in DM-225)"
Answer: 204201.0

User story: This came up in the review of CSS, see DM-225:  QservAdminImpl: so, if there's a problem while inserting the various keys for a database, and another exception during cleanup, you can end up with a partially constructed database. How do you plan on handling this? This is perhaps another argument for trying to batch metadata more - if it's all in a single key, this worry goes away (at least in this particular case). The createDb implementations seem racy. Consider what happens if 2 admins try to create the same database D. Suppose admin A does the _dbExists(D) check first; it returns false. Then admin B comes along, and does the same check, which returns false again. Let's further suppose that admin B successfully issues all the key creates for D without being interrupted by A. Back to A: when A tries to create all the keys required for D, an exception will be raised immediately since D exists. At this point A will dutifully try to clean up (to avoid leaving around a partially constructed D), deleting D as created by B. End result: D was successfully created, no explicit drop was issued, but D does not exist. Database drops can also race with table creates: zookeeper doesn't have a native recursive delete. In other words, it is perfectly possible for an admin A to issue a database drop while someone else is issuing a table create. The recursive delete might descend into the table "directory" while the create is populating it with child znodes. The recursive delete will get an incomplete list of children, remove them, and finally fail to remove the table directory because the table create has since added more children, and it is illegal to remove a non-empty directory. At this stage, the drop will report success even though it has failed (that's the recursive delete behavior that kazoo gives you), and the table create will report success. But the database will still exist, and table keys may be partially present in zookeeper.
Answer: 81971.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Like DM-440, but we should also have a comment box when we move to Done, as that's when we often record how we've responded to trivial review comments."
Answer: 1483133.0

User story: "1) Change lsst.qserv.master to  lsst.qserv.czar in the czar module.  2) Rename masterLib to czarLib  3) Rename startQserv to startCzar "
Answer: 21495.0

User story: "Fix problems with threads in watcher.py brought up in DM-225 by Serge:  * A thread per database doesn't scale  * There is a thread leak when a database is deleted  * There is another design problem, in that each database thread looks like it is holding on to the same lsst.db.Db instance under the hood. I don't remember any consideration for thread safety from the lsst.db code when I reviewed it. Note for one that it is not safe to use a MySQL connection simultaneously from multiple threads (and I seem to recall that you are caching a connection inside Db instances). In practice, even the Python GIL may not save you, since calls into C code (i.e. the mysql client library) may very well release it."
Answer: 263235.0

User story: "There seem to be confusion about driving table and secondary index. At the moment in zookeeper structure we have {code} /DATABASES/<dbName>/objIdIndex /DATABASES/<dbName>/TABLES/<tableName>/partitioning/secIndexColName /DATABASES/<dbName>/TABLES/<tableName>/partitioning/drivingTable /DATABASES/<dbName>/TABLES/<tableName>/partitioning/latColName /DATABASES/<dbName>/TABLES/<tableName>/partitioning/lonColName /DATABASES/<dbName>/TABLES/<tableName>/partitioning/keyColName {code}  Issues to think about:  * we can't call it objIdIndex, it is too lsst-specific.  * drivingTable and keyColName - perhaps these should be at database level, which means we would only allow one drivingTable and one secondary index per database?  * or, maybe instead of database level, it is a partitioning parameter? Note that two databases might use different name for secondary index or driving table, yet they might be joinable. That argues for introducing a new group, something like /DATABASE/partitioning in addition to /DATABASE_PARTITIONING.  * consider renaming drivingTable to keyTable  * do we really need secIndexColName and keyColName? Can't we get rid of one, and rename to keyColName? "
Answer: 43228.0

User story: "It is meant to be used to indicate L1, L2, L3... At Qserv design week we decided to rename it (original plan was to remove it all together) "
Answer: 27243.0

User story: "rename DATABASE_PARTITIONING to PARTITIONING  rename DATABASES to DBS"
Answer: 37460.0

User story: "Generating the kvmap file, and pasting it into a string inside the test program. (this was brought up in DM-225)"
Answer: 193535.0

User story: "Build the kvMap at build-time and embed it into the executable. (this was brought up in DM-225)"
Answer: 322624.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Base DMCS Alert Production Cluster  The Alert Production Cluster receives commands from the OCS, and performs the following actions:  * init - Move from OFFLINE mode to IDLE state.  * configure - (arguments:  set of computers to use, the software to be executed, and parameters to control that software).  1) Verify format and accept command; 2) change to disable mode as if a disable command had been received; 3) install configuration;  4) return success to the OCS.  On failure (illegal configuration, cannot be installed properly), a command error with the failure reason is sent to the OCS.  Prerequisite for configure command - sufficient workers are available.  Note that after configure, the Alter Production Cluster remains disabled.  * enable - Causes the Base DMCS to subscribe to the “nextVisit” topic in normal science mode; another event may be subscribed to in calibration or engineering mode.  * disable - Causes the Base DMCS to unsubscribe from the “nextVisit” topic.  It does NOT terminate any worker jobs already executing.  In particular, the processing for the current visit (not just exposure) will normally complete.  * release - Unsubscribe to the startIntegration event, and go into OFFLINE state.  * abort - if received during a configure command, causes this component to go into the ERROR state with no configuration.  If received at any other time, the system transitions into an ERROR state, but nothing stops that was already in progress.  * reset - Unsubscribe to the startIntegration event, go into IDLE state, with no configuration"
Answer: 180198.0

User story: "Base DMCS EFD Replicator  The EFD Replicator receives commands from the OCS, and performs the following actions:  * init - Move from OFFLINE mode to IDLE state.  * configure - (arguments:  set of computers to use, the software to be executed, and parameters to control that software).  1) Verify format and accept command; 2) change to disable mode as if a disable command had been received; 3) install configuration;  4) return success to the OCS.  On failure (illegal configuration, cannot be installed properly), a command error with the failure reason is sent to the OCS.  Prerequisite for configure command - communication with the US DAC EFD replica is possible.  Note that after configure, the EFD Replicator remains disabled.  * enable - Causes the Base DMCS to enable the US DAC EFD replica to be a slave to the Chilean DAC EFD replica.  * disable - Causes the Base DMCS to disable the slave operation of the US DAC EFD replica.  * release - Unsubscribe to the startIntegration event, and go into OFFLINE state.  * abort - if received during a configure command, causes this component to go into the ERROR state with no configuration.  If received at any other time, the system transitions into an ERROR state, but nothing stops that was already in progress.  * reset - Unsubscribe to the startIntegration event, go into IDLE state, with no configuration"
Answer: 180199.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Base DMCS Catch-Up Archiver  The Catch-Up Archiver receives commands from the OCS, and performs the following actions:  * init - Move from OFFLINE mode to IDLE state.  * configure - (arguments:  set of computers to use, the software to be executed, and parameters to control that software).  1) Verify format and accept command; 2) change to disable mode as if a disable command had been received; 3) install configuration;  4) return success to the OCS.  On failure (illegal configuration, cannot be installed properly), a command error with the failure reason is sent to the OCS.  Prerequisite for configure command - sufficient catch-up-dedicated replicator/distributor pairs are available.  Note that after configure, the Archiver remains disabled.  * enable - 1) Allows Catch-Up Archiver to scan for unarchived images to be handled; 2) Enables the Orchestration Manager to schedule image archive jobs.  * disable - 1) Stop scanning for unarchived images; 2) Tell the Orchestration Manager to stop scheduling any new image archive jobs.  * release - Unsubscribe to the startIntegration event, and go into OFFLINE state.  * abort - if received during a configure command, causes this component to go into the ERROR state with no configuration.  If received at any other time, the system transitions into an ERROR state, but nothing stops that was already in progress.  * reset - Unsubscribe to the startIntegration event, go into IDLE state, with no configuration"
Answer: 200237.0

User story: "Base DMCS Archiver  The Archiver receives commands from the OCS, and performs the following actions:  * init - Move from OFFLINE mode to IDLE state.  * configure - (arguments:  set of computers to use, the software to be executed, and parameters to control that software).  1) Verify format and accept command; 2) change to disable mode as if a disable command had been received; 3) install configuration;  4) return success to the OCS.  On failure (illegal configuration, cannot be installed properly), a command error with the failure reason is sent to the OCS.  prerequisite for configure command - sufficient replicator/distributor pairs are available.  Note that after configure, the Archiver remains disabled.  * enable - Subscribe to the startIntegration event.  * disable - Unsubscribe to the startIntegration event.  Note that this does NOT terminate any replicator jobs which are already executing.  * release - Unsubscribe to the startIntegration event, and go into OFFLINE state.  * abort - if received during a configure command, causes this component to go into the ERROR state with no configuration.  If received at any other time, the system transitions into an ERROR state, but nothing stops that was already in progress.  * reset - Unsubscribe to the startIntegration event, go into IDLE state, with no configuration"
Answer: 181306.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "From HipChat/Data Management:  [12:09] <USER> @<USER>@KTL @KSK Could you double-check if any of you got an e-mail from Jira on Saturday (Apr 12th) re issue DM-78 (I made you reviewers, but it looks like you weren't notified)? [12:10] K-T Lim: I don't recall and can't determine now; it would have been deleted (irrevocably). [12:10] <USER> I did get an email. [12:10] <USER> @<USER> ah, it appears that I actually did.  The fact that I was a reviewer was just buried, and I didn't notice it. [12:10] <USER> I must have missed that I was a reviewer. [12:10] <USER> OK, thanks!   That gives me not one, but two useful data points (#1 -- emails work, #2 -- they're useless :) ). [12:12] <USER> I'm not sure why they are useless.  The emails from trac were a very important part of my workflow as far as being notified of review responsibility goes.   Maybe it's just the volume from Jira. [12:14] <USER> Yeah, same here.  Though the volume from JIRA hasn't been so bad, so I don't think that's it.  Maybe my brain just has to get used to the new email format. [12:14] K-T Lim: (In my case, I'm mostly paying attention to the RSS feed although the mailbox serves as a backup.) [12:22] <USER> One of the things that made gnats a good bug tracker was that the emails contained the right amount of information (I did have source code...), and trac was pretty good too when we tuned it;  bugzilla always used to be awful.  I bet we can fiddle with Jira to make its mail more useful;  I don't just mean filtering what it sends, but making sure that each email is self contained, but not too long"
Answer: 281417.0

User story: "This is a test issue, please ignore it."
Answer: 461.0

User story: "The SFM photometric calibration is currently part of the meas_astrom product (although imported as {{lsst.meas.photocal}}).  It needs to become its own top-level product.  We should take the opportunity to rewrite it (along with meas_astrom).  For example, it currently hardwires algorithm names rather than using configs to specify types of algorithm.  "
Answer: 375673.0

User story: "Need to update the data management section of the LSST overview paper for the PST/Zeljko. Needs to be finished by ~end of April."
Answer: 297958.0

User story: "Hello,  Tests target seems to be correctly defined in core/modules/SConstruct (cf. getTests() function), but tests doesn't seems to be nor built or runned.  In DM-58 branch i've introduced a few line of code which now build the tests.  For now, tests binaries are located in build/moduleName/ directory, do you think we should let the tests here or install it :  - in the Qserv install directory ? - in a tests/ subdirectory of Qserv install directory ? - other solution ? - do we set an option to scons procedure in order to build, and run, these unit tests ?  Thanks,  Fabrice"
Answer: 43878.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Document how to create astrometry_net_data index files for an arbitrary astronomical dataset, as well as how to create a repository of such data to support processing with the LSST Stack. It must be possible to limit the area of sky coverage in the index files to that appropriate for the images that the user wishes to process. "
Answer: 47552.0

User story: "At the DMLT meeting in Seattle, finish the backlog prioritization for Summer 2014 cycle.  Definition of Done: * All epics and major stories defined for Summer 2014. * Rank-ordered in terms of priority. * Leadership teem agreement on their prioritization and backlog. * Teams identified to execute the stories, and stories labeled accordingly. "
Answer: 457806.0

User story: "Develop an iPython Notebook to illustrate the processing and results of the LSST Demo. This can be used as both a basic tutorial for the Stack, and a how-to for creating additional visualizations for DM. The visualization should include the source catalog, and possibly also one or more of the processed images. "
Answer: 171378.0

User story: "Create a worked example in the Software User Guide of processing raw data with obs_lsstSim. The example should include:   - Pointers to documents for creating multi-band, raw datasets with PhoSim - Creating a data repository for the data - Creating an astrometry_net_data repository - Processing raw files through processCdc (including ISR, measurement, etc.) - Creating a catalog of measurements - Visualizing the output using existing tools  It is possible to work initially with a limited set of data (a raft, or CCD), and to start with eImages rather than raw; the example can be elaborated in due course."
Answer: 138224.0

User story: Rework exceptions in css/KwInterface.py: split into key-value related exceptions, possibly moving the rest that deals with db/tables into client.  This came up in the CSS review, see DM-225: "CssException feels a bit out of place...."
Answer: 37370.0

User story: "The config item in the old measurement task, measurement.algorithms was changed to measurement.plugins in meas_base.  The creates a backward compatibility issue for code which refers to this class member.  Jim's suggested fix is to alias plugins with algorithms in the new measurement task."
Answer: 35820.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "change lsst-build interface to:   * rename 'prepare' to 'clone'   * use current directory to clone to   * remove the default REPOSITORY_PATTERN, as it isn't complete   * use the current username as default build tag prefix   * don't write the manifest by default; use --manifest=<filename> option instead   * refuse to change/overwrite repositories if they're dirty, use --force to override   * create a separate 'version' verb   * ProductFetcher.fetch doesn't need to return ref, sha1   * read config file within build directory, .btconfig   * rename the binary to bt   * have the versioner use git db by default, but fall back to generating versions from hash by default  See the linked web page for a mock of the command line interface."
Answer: 458115.0

User story: We need to have both "fatal" and "suspect" flags to handle different levels of warnings in measurement.  (other tasks previously included on this ticket have been split into other tickets, including DM-461 and DM-984)
Answer: 409944.0

User story: "SkyCoord was moved to DM-441 - done in Python  Classification is also simple if done in Python  Pixel Keys will be done in C++  Some work left from SdssShape will be done with this ticket  Also, since these are out only two Python algorithms in the base set, I will add the exception handling and base fail() methods at this time. "
Answer: 36223.0

User story: "Some measurement failures are global for a whole exposure, such as a missing Psf or Wcs.  The framework currently does not distinguish this from a failure in a single measurement.  Should add a new subclass of MeasurementError which can be thrown in these cases.  Should also add configuration option to the measurement framework to determine what should be done with this type of error.  We should also add an exception class and associated how-to-handle config for problems that indicate that something has gone wrong in pre-measurement processing, such as NaNs in the image."
Answer: 244325.0

User story: It'd be very useful to have a way to "dump" and "restore" entire contents of the key/value store in zookeeper. The dump part is pretty much there (can dump to an ascii file) 
Answer: 46028.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "I suspect this might be supplanted by the new logging system, but if it isn't, I wanted to get this issue documented here.  The version of the bin/Logger.py object included and started by Orca needs to be re-worked, if we intend to Orca to handle putting messages in the logging table of the database.   The current mechanism used is to have a process (bin/Logging.py) launched which monitors the logging topic, and puts messages into the database.  When there are large numbers of messages, this becomes a big bottleneck. In previous iterations of the pipelines, (DC2 and possibly DC3), the Logging process would have a significant backlog of messages to process long after the pipelines ended.  No messages were lost, but it did take a very long time for the queue to be drained.  In order to speed up the db inserts, the current version uses a shared memory file which would be used to write database records.  This in turn is sent to the database.  This isn't portable, and we just need a better mechanism to deal with this issue.  If the logging messages continue to be translated into DM events/messages, another solution to explore is to have the ActiveMQ broker insert those messages itself.  There are hooks in ActiveMQ to do this, but I haven't explored this.  The hooks would have to be written in Java.  This should use the DbAuth from daf_persistence, rather than having its own too."
Answer: 1563550.0

User story: "Currently you can attach files to issues, but not screenshots.  This is a nuisance.  Fortunately there's a free plugin that claims to support this;  can you install it?  https://marketplace.atlassian.com/plugins/com.atlassian.plugins.jira-html5-attach-images"
Answer: 322086.0

User story: "It's possible to add attachments, but not delete them.  For example, I just added some to DM-104 but it turned out that jira can't really handle tiff, so I'd like to replace them.... but I can't.  See https://confluence.atlassian.com/display/DOC/Deleting+an+Attachment "
Answer: 6859.0

User story: "When the .paf to config switch happened, it was decided to push off the recording of provenance to a later date.  The old mechanism was set up to record software package names, version, and directories.  It also recorded the .paf files for the policies that were used to configure the pipelines.  We need a mechanism to record this information for software packages and the Config files used to configure the runs.  I suspect this still belongs in ctrl_orca, but we might consider shifting this to ctrl_execute because it has additional information that I think we'd like to have as part of the record of provenance of the run.  The tests for this in ctrl_orca broke when this change over happened, so those need to be fixed as well."
Answer: 2116581.0

User story: "We need a unit test that would automatically detect problems with starting/stopping services. An example of a problem that we should automatically catch is in DM-328."
Answer: 203294.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: The CModel code we want to transfer from HSC in DM-240 currently relies on the old "multishapelet.psf" algorithm in meas_extensions_multiShapelet.  That means we either need to convert that PSF-to-shapelets code in meas_extensions_multiShapelet to use the meas_base interface, or we need add new PSF-to-shapelets code in meas_multifit.  I think the latter is the better choice, even if we delay DM-240 as a result; the heavy algorithmic code is already available as primitives in meas_multifit, so it should just be a matter of packing those into a simple driver, creating a config class for it, and testing it on a few real and simulated PSFs to learn reasonable defaults for the configs.
Answer: 242315.0

User story: "Similar to DM-441, but for Aperture Flux  Should include tests of major config options to be sure that they do something reasonable.  Should include test of at least one exception (flag)"
Answer: 88621.0

User story: "Test for compatibility of NaiveFlux, GaussianFlux, and PsfFlux against meas_algorithms  "
Answer: 57653.0

User story: "Similar to DM-441 for flux algorithms GaussianFlux and NaiveFlux  Unit tests for major config options, just to be sure that they do something reasonable.  Test of at least one exception (flag)"
Answer: 37706.0

User story: "Move PeakLikehoodFlux to meas_base framework "
Answer: 175694.0

User story: "Do a trial run of a small area of sky (using a single exposure from measMosaicData).  First create a source catalog using the old measurement.py, then run the same test with the measurement task in sfm.py.  Compare the results.  If the code has been ported correctly, they should match."
Answer: 57673.0

User story: "-------- Original Message -------- Subject: Getting HipChat licenses Date: Wed, 09 Apr 2014 08:51:46 -0700 From: <USER><<EMAIL> Organization: Large Synoptic Survey Telescope Inc. To: Jeffrey Kantor <<EMAIL>, <USER><<EMAIL>>,  Stefan Dimmick <<EMAIL>  Jeff et al.,  I'd like to start the process to acquire HipChat licenses (we have 10 days left on our evaluation one). Right now we have 26 users, so our first total would be $52/month. I'm expecting it will eventually grow to ~50 users or so.   In terms of an account to charge, this should really be considered a project-wide tool, but if that's going to cause unnecessary delays I'd propose we charge it to DM as a sign of our infinite kindness and good will :).   HipChat wants to simply bill a credit card -- once we get the necessary approvals, Iain, I can add you as an admin, and you can use our corporate one if that's OK. "
Answer: 6821.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The goal of this story is to take the following algorithms and make them fully operational with processCcd.  PsfFlux,SdssShape,SdssCentroid,SincFlux.  This code was moved to meas_base in w14, but has yet to be used in full operation.  This is the first step in that process.  Each algorithm will at least have one test to confirm that it works, but the unit tests will be very simple.  The actual confirmation of full operability will the to run tests against real data, and compare against the existing meas_algorithms.  The algorithm code will still require cleanup even after this story is completed.  That is because it has intentionally been left the same as what existed in meas_algorithms.    The goal of this ticket is to confirm that the each algorithm can (1) complete its measurement with some reasonable result, (2) responds to its major configuration options, and (3) handles at least some of its defined exceptions (that is, flags) correctly.  Confirmation that the results are identical with meas_algorithms is a subsequent ticket  Cleanup and documentation of this code will be done in a subsequent ticket."
Answer: 21416.0

User story: "Currently, when we switch from To-Do to In Progress, we get a box asking for a comment.  I think this is unnecessary, but not a serious problem.  However, we do not get such a box when we switch from In Review to Review Complete, and here I think having a comment box is highly desirable: I virtually always want to make a comment when I complete a review, and I'm assuming doing it in a pop-up box cuts down on unnecessary notifications."
Answer: 38.0

User story: This depends on whether or not we're going to be sending "real" VOEvents, or if we're simulating that too:  There appear to be several different VOEvent software packages out there.  We need to evaluate and select which package we'll use.  We'll want to consult with Ray about this.
Answer: 1006582.0

User story: "We need to interpolate the aperture correction to the position of every source, and apply this correction to all appropriate fluxes.  The HSC implementation of this work (as well as that of DM-435) was done on issue HSC-191: https://hsc-jira.astro.princeton.edu/jira/browse/HSC-191 There were changes to many packages, but the relevant ones for LSST are: https://github.com/HyperSuprime-Cam/afw/commit/057fb3c0581c512d5664f1883a72da950c9eae9d https://github.com/HyperSuprime-Cam/meas_algorithms/compare/HSC-3.0.0...u/<USER>DM-191 https://github.com/HyperSuprime-Cam/pipe_tasks/compare/4c3a53e7238cbe9...u/<USER>DM-191  Note that on the LSST side, we'll want to apply the aperture corrections either within a new plugin in meas_base or as a new part of BaseMeasurementTask, not as a change to the CorrectFluxes algorithm (which will be removed in the future along with the rest of the old measurement framework in meas_algorithms)."
Answer: 668359.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "At the end of CalibrateTask, we'll want to compute the PSF and aperture fluxes of the PSF stars, and send those to the PSF model to be stored and interpolated (using the featured added via DM-434).  We'll also need to run any other flux measurement algorithms that need to be tied to the PSF fluxes on these same stars; because these can be somewhat slow, we probably want to limit these measurements to only the PSF stars, rather than requiring all these algorithms to be run as part of calibrate.measurement.  The relationships between these fluxes and the PSF fluxes will be additional fields to be added to and interpolated by the PSF.  The HSC implementation of this work (as well as that of DM-436) was done on issue HSC-191: https://hsc-jira.astro.princeton.edu/jira/browse/HSC-191 There were changes to many packages, but the relevant ones for LSST are: https://github.com/HyperSuprime-Cam/afw/commit/057fb3c0581c512d5664f1883a72da950c9eae9d https://github.com/HyperSuprime-Cam/meas_algorithms/compare/HSC-3.0.0...u/<USER>DM-191 https://github.com/HyperSuprime-Cam/pipe_tasks/compare/4c3a53e7238cbe9...u/<USER>DM-191"
Answer: 659545.0

User story: "The slot mechanism in afwTable currently uses compound fields to save the 3 slot types:  flux, centroid, and shape.  Since the new measurement framework uses a flattened representation in the SourceTable where these types are saved as multiple scalar fields, the slot mechanism need to be altered to handle this new table type.  1.  An alternative to KeyTuple for storing the keys required by the slot 2.  Fixup get(Centroid, Flux, Shape) in SourceRecord to use correct keys. 3.  Fixup the single value getters (getX, getY, etc) to use the correct keys. 4.  Persist slot info to fits correctly, based on table version."
Answer: 31823.0

User story: "Add remote access to the Event Monitor to monitor.  Since the Event Monitor is meant to be a long-lived process, there should be a good way of getting information from it while it's running.   We could watch to see which rules were in place, which Chains were active, and what their current state is, and for general debugging.  The JMX would be a good way to explore some of this, but if the event monitor were re-written, it couldn't be used.  Besides, it requires the use of jconsole, and it wouldn't be as easy to read/use as watching this information through a browser, or the command line."
Answer: 1058352.0

User story: A "shelf life" timer should be implemented to optionally expire Chains that are unfulfilled.  Currently Chains are retained indefinitely.  This shouldn't be a required or automatic expiration, since some Chains may be very long-lived.   It also shouldn't be implemented as an Exception, since that term has its own implications.  This should be based on either the number of messages seen before expiring, or the amount of time since the last Conditional was matched.  It probably should be a superclass of Exception.
Answer: 1058382.0