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: "Please summarize node utilization for RC2 jobs for w_2018_15 w_2018_17 w_2018_18, and add the results to the confluence page.      The slurm job IDs are as follows:    w_2018_15  133039,133225,133227,133226,133229,133228,133272,133281,133273,133283,133282,133230,133232,133231,133234,133233,133235,133353,133357,133359,133355,133350,133358,133339,133341,133340,133343,133342,133361,133364,133362,133366,133365,133688,133840,133691,133686,133021,133024,133028,133023,133027,133025,133015,133018,133016,133020,133019,133009,133011,133010,133014,133013,133243,133245,133247,133244,133248,133246,133237,133240,133239,133242,133241,133275,133286,133276,133288,133287      w_2018_17  138558,138564,138566,138565,138568,138567,138559,138561,138560,138563,138562,138589,138591,138590,138593,138592,138594,138607,138609,138611,138608,138612,138610,138602,138604,138603,138606,138605,138597,138599,138598,138601,138600,138619,138637,138618,138617,138552,138554,138557,138553,138556,138555,138547,138549,138548,138551,138550,138542,138544,138543,138546,138545,138584,138586,138588,138585,138595,138587,138579,138581,138580,138583,138582,138569,138571,138570,138573,138572      w_2018_18  138908,138918,138920,138919,138922,138921,138913,138915,138914,138917,138916,138923,138925,138924,138927,138926,138929,138956,138958,138961,138957,138960,138959,138951,138953,138952,138955,138954,138946,138948,138947,138950,138949,138963,138962,138902,138904,138907,138903,138906,138905,138897,138899,138898,138901,138900,138892,138894,138893,138896,138895,138940,138942,138944,138941,138945,138943,138935,138937,138936,138939,138938,138930,138932,138931,138934,138933,139022,139023  "
Answer: 253.0

User story: "[~<USER> writes:  {quote}  GCC 8.1 was released recently, and it told me the following mistake in AFW.   The mistake resides in the master branch, too.  {code}  diff -ur afw-6.2-hsc+1/src/detection/FootprintSet.cc afw-6.2-hsc+1.new/src/detection/FootprintSet.cc  --- afw-6.2-hsc+1/src/detection/FootprintSet.cc    2018-04-18 14:36:08.000000000 +0900  +++ afw-6.2-hsc+1.new/src/detection/FootprintSet.cc    2018-05-08 15:07:26.862308982 +0900  @@ -876,7 +876,7 @@       Startspan(geom::Span const *span, image::Mask<MaskPixelT> *mask, DIRECTION const dir);       ~Startspan() { delete _span; }     -    bool getSpan() { return _span; }  +    std::shared_ptr<geom::Span const> getSpan() { return _span; }       bool Stop() { return _stop; }       DIRECTION getDirection() { return _direction; }  {code}  {quote}"
Answer: 4370.0

User story: "Change FITS image reading so the the specified index is the fits HDU index and not the image count index. For example, currently if there are 7 HDUs with a order of    I - I - T - T - I - T - I. The the image indexes are 0-3, not 0,1,4,6. This should be changed. The correct ones should be 0, 1, 4, 6.    This will make the image and table reading consistent.          "
Answer: 355607.0

User story: "Split jupyterutils into Lab and server packages."
Answer: 9905.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: "Start to go through the FIXME integration test queries and determine if they are FIXME because they fail to parse, or if they fail to run. Take notes on which is which. Make some effort to figure out why they don't run (with the acknowledgment that it may take 20 story points to chase down even 1 non-running query for a qserv novice).    The output of this will be compared with [query pages in TRAC|https://dev.lsstcorp.org/trac/wiki/db/queries] (being ported to Confluence by [~<USER>), and stories to fix these stories will be created as appropriate."
Answer: 93754.0

User story: "In DM-14335 the final list of requirements was submitted. They need to be transferred to the model and converted to a docgen for review by DM CCB."
Answer: 24757.0

User story: "The database performance metrics promoted from LDM-135 and the ability to calculate the key performance metrics specified in OSS, must be submitted to project CCB for approval. If there are any performance metrics we rely on but which are not yet in LSE-61 now would be a good time to add them."
Answer: 204472.0

User story: "Run matchedVisitMetrics.py validateDrp.py and reportPerformance.py with the HSC RC2 w_2018_18 outputs from DM-14243."
Answer: 220.0

User story: "Run   # visitAnalysis   # coaddAnalysis   # colorAnalysis   # compareVisitAnalysis   # compareCoaddAnalysis    with the w_2018_18 RC2 outputs from DM-14243    Use the tickets/DM-13154 branch "
Answer: 1669.0

User story: "Reprocess the HSC RC2 dataset, as defined in DM-11345, using Stack w_2018_20. Steps include {{makeSkyMap.py}}, {{singleFrameDriver.py}}, {{mosaic.py}}, {{skyCorrection.py}}, {{coaddDriver.py}}, and {{multiBandDriver.py}}. "
Answer: 21543.0

User story: "Test installation and deployment of mpi cluster within kubernetes"
Answer: 164470.0

User story: "Resulting from this proposal [^Gemini_032116.pdf]    250 exposures were obtained [^exp.list]    A fist look at the data is being done : here is an illustration of the raw spectrum of the standard star TYC 9511-1775-1    !Capture d’écran 2018-05-07 à 12.57.21.png!"
Answer: 66615.0

User story: "Unify the k8s definition of the proxy container for worker and master pods."
Answer: 24939.0

User story: "Logic is described by Jim in [https://dmtn-056.lsst.io/operations.html#supertask-pre-flight-and-execution.] There are many complications of course, e.g. what is Registry responsibility vs. Pre-flight responsibility. First implementation will likely be sub-optimal and ugly.     "
Answer: 90366.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: While Oracle RAC at NCSA is getting ready for testing I could spend some time to try running my prototype against Oracle in some other non-production setup. ap_proto uses sqlalchemy but it also has dialect-specific SQL handling for optimization purpose. I need to extend that backend-specific code to support Oracle as well.     I can think of few potential things that need different implementation for Oracle:   * multi-row INSERT, Oracle does not support syntax that is supported by other backends (\{\{INSERT INTO TABLE (columns) VALUES (data), (data), (data), ...}}) so I'll have to find some other mechanism for bulk row insert   * "UPSERT" functionality should also be implemented differently in Oracle   * Case-sensitivity issue (probably minor)   * Usual DATETIME stuff is not very portable   * Anything else...
Answer: 39934.0

User story: "In dax_imgserv_v1, a module metaservGet is currently containing a SQL call to retrieve metadata for nearest image based on RaDec. This functionality should  be provided by dax_metaserv API as a basic use case. We need to understand how this might be implemented."
Answer: 3.0

User story: "The idle culler broke at some point because it's using a mixture of tz-naive and tz-aware dates.  Fix that."
Answer: 3.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: HSC weekly re processing is now producing verification jobs, located at  {noformat} /datasets/hsc/repo/rerun/RC/w_2018_17/DM-14055/validateDrp/matchedVisitMetrics/*/*/*json  {noformat}  This ticket is to start a discussion of what is needed to send those results to SQuaSH.   - {{dispatch_verify.py}} is used to send a verification job to SQuaSH, it has the {{--env}} option that can be used to grab information from the environment which is added to the job metatada. That's used by SQuaSH to identify the dataset being processed, the ID of the run, URLs linking to additional information about the run, the stack version used, etc.    For CI we defined a "jenkins" enviroment, here we need to create another environment option named perhaps {{ldf}}. My initial suggestion for the environment variables is:   - {{DATASET}}: name of the database being processed, e.g HSC RC2   - {{DATASET_REPO_URL}}: do we have a git lfs repo for the dataset?   - {{RUN_ID}} : can we use the associated jira ticket to identify this run? following [https://confluence.lsstcorp.org/display/DM/Reprocessing+of+the+HSC+RC+dataset] it looks like a good idea, is there a better identifier for the runs?   - {{RUN_ID_URL}}: could be the corresponding jira ticket URL   - {{VERSION_TAG}}: the LSST stack version used, e.g {{w_2017_14}}    Once this new environment is created in {{dispatch_verify.py}} an example of command line to publish the results to SQuaSH would be:  {noformat}$ export DATASET="HSC RC2"  $ export DATASET_REPO_URL=""  $ export RUN_ID="DM-10084"  $ export RUN_ID_URL="https://jira.lsstcorp.org/browse/DM-10084"  $ export VERSION_TAG="w_2017_14"    $ dispatch_verify.py --url https://squash-restful-api-demo.lsst.codes --user <squash user> --password <squash passwd> --env ldf --lsstsw lsstsw/ output/verify/job.json     {noformat}  Note that the above URL points to a demo instance of SQuaSH so we can test as needed without affecting the production instance.    Here I am assuming we have an lsstw stack installation and thus access to the manifest file with the versions of the stack packages. We can supress the {{--lsstsw}} but it would be useful to carry on this information to compare which stack packages changed from weekly to weekly build.   - [~<USER> mentioned that we have one verification job per patch. I guess, as a start, we could publish result for one patch only? Later, one way to do that would be to add the patch id as a job metadata so that we can distinguish them on SQuaSH. Also, we can use {{dispatch_verify.py}} to combine multiple verification jobs into a single JSON if that is required (see [https://sqr-019.lsst.io/#Post-processing-verification-jobs]) but this wouldn't scale if we process many patches which will be the case.
Answer: 107769.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: "There's code to ensure that consistent versions of pipelines are used, but it fails when you have code that isn't fixed into git.    The problem is that in {{packages.py}} the non-git code is fingerprinted using e.g.    {{git --no-pager --git-dir=/Users/<USER>LSST/display/matplotlib/.git --work-tree=/Users/<USER>LSST/display/matplotlib diff --patch}}    and that includes lines like    {{< --- /var/folders/l9/yttb8nyx1kq23llj2hny2yhw0000gq/T//VY36bc_display_matplotlib.ipynb  2018-05-04 17:04:31.472292}}    with a date stamp.  We need to trim them out before calculating their SHA1"
Answer: 3939.0

User story: "We would like to allow arbitrary tags and a choice of container sizes.  See how feasible this is."
Answer: 7212.0

User story: "Because {{makeStorageClass}} creates new {{StorageClass}} subclasses dynamically instead of instances they can't be pickled (since unpickling tries to look up the class name which doesn't actually exists). This could be solved in multiple ways, but the easiest is to simply make individual {{StorageClass}} entries (in {{StorageClassFactory}}) instances instead of subclasses. Then also get rid of {{makeStorageClass}} and just use the constructor."
Answer: 86.0

User story: "Design, set up, execute, and write up precursor tests for LDM-503-4 and cross-subsystem Spectrograph integration activity."
Answer: 3.0

User story: "[~<USER> requests that patchId be a column in the {{deepCoadd_obj}} table, which makes sense (I'm currently creating it in {{writeQATableTask}}, but seems sensible that users might want it earlier)."
Answer: 570662.0

User story: "The python scripts that was developped to reduce CTIO 0.9m telescope observations has been made available for discussion on github :    [https://github.com/guyonnet/slitless_image_reduction]"
Answer: 70991.0

User story: Per [~<USER>, dax_metaserv should be populated for everything we are serving through PDAC.     http://lsst-qserv-dax01:5000/meta/v1/db/ should have one logical database entry for WISE with multiple schemas corresponding to each of the PDAC database described here:    https://confluence.lsstcorp.org/display/DM/PDAC+v2+data+list     (Similarly to how we have sdss_stripe82_01 in the schemas section returned by sst-qserv-dax01:5000/meta/v1/db/W13_sdss_v2/)    We should only populate metaserv with the data readily available from dbschema ("name", "datatype", "nullable)". All other fields like "ucd", etc. can be empty.    This would make it possible for SUIT to refer to WISE tables using logical database name rather than internal name like `"//lsst-qserv-master01:4040".wise_00.allwise_p3as_mep` and make sure that WISE data can be discovered through TAP like services.    5/10/2018 tgoldina  Since there is no optimized way to get table column metadata via dbserv, this issue is a blocker for moving PDAC to dbserv v1 (albuquery). Please consider it when deciding on the priority of this ticket.      
Answer: 80336.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: "Some of the QA tools now need pyarrow.  Please install pyarrow with the other third party modules."
Answer: 64.0

User story: "Deliver a 404 page via Fastly if the underlying object does not exist in the S3 bucket. This good UX, and also prevents S3's error pages from being cached.    This tutorial provides a good start: https://docs.fastly.com/guides/basic-configuration/creating-error-pages-with-custom-responses.html"
Answer: 11743.0

User story: "I read the developer guide's logging docs and reviewed and tested cModel's logging. In short, the optimizer has detailed debug statements, but there is very little output from cModel itself describing the control flow. For example, one galaxy was running the double shapelet PSF fitting tasks but skipped the cModel routine, as modelfit_CModel_flag_region_maxBadPixelFraction was set. I also spent some time (re)discovering that some ipython output gets sent to jupyter's stdout for reasons I don't understand (possibly this bug: https://github.com/gotcha/ipdb/issues/52)."
Answer: 55954.0

User story: "With assistance from Nate, I learned how to use the measurementInvestigationLib in meas_base to create and rerun SingleFrameMeasurementTasks. I refactored some of my jupyter notebook into convenience functions to easily rerun CModel on individual objects. These scripts (modified since I wrote this ticket) are now available at https://github.com/lsst-dm/modelling_research    In addition, we found some code rot in lsst.meas.base.measurementInvestigationLib and I filed a separate ticket for it (DM-14534)."
Answer: 46442.0

User story: "Implementation of RFC-479.    For now, this is exploratory work, to see just how bad the changes to ndarray are going to be."
Answer: 92454.0

User story: "NCSA would like us to add a blacklist to the authenticator.  Should be straightforward-ish."
Answer: 1375.0

User story: "Now that Python 2 is not supported, we can remove all the items in the Python style guide talking about Python 2 and {{__future__}}/{{futurize}}."
Answer: 242.0

User story: "It shows that you can use Holoviews to create a visualization in the notebook, convert that to a Bokeh app and use the Bokeh server to run your visualization as a standalone app inside JupyterLab.  "
Answer: 11881.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: jointcal's {{PerTractCcdDataIdContainer}} doesn't have any tests, so its exact behavior given various inputs is not entirely clear. We should add some tests for it using some fake visit/tract combinations: list of visits all in a tract; list of tracts with no visits; list of visits in different tracts, would be a good start.    As part of this, we should explore merging the existing versions of this code into one, so that the code and tests only live in one package (possibly {{pipe_base}}? Or maybe {{daf_butler}}?). Possibilities to include in this unification include:    * {{jointcal.dataIds.PerTractCcdDataIdContainer}}  * {{meas.base.forcedPhotCcd.PerTractCcdDataIdContainer}}  * {{coadd.utils.CoaddDataIdContainer}}  * {{pipe.tasks.assembleCoadd.AssembleCoaddDataIdContainer}}    This should wait for Gen3 Butler, as that will eliminate the "Reading WCS to determine tracts" part of the code, since making up fake WCSs would make writing the test much harder.
Answer: 774106.0

User story: "Document KPM30 results in DMTR-71."
Answer: 635276.0

User story: "Major milestones of this effort:  # upgrade Qserv installation in PDAC with the latest version of Docker containers based on MariaDB 10.2.14. The new containers are also needed to support the extended management protocol needed for cooperation between Qserv workers and the Replication system's Controllers when changes to replica disposition are made.  # Docker-based install and preliminary tests of the Replication system's tools on the cluster. At this stage a proper configuration of the Replication system will be devised and tested.  # Scalability tests of the main replication operations, including operations with persistent state of the operations (Replication _jobs_ and _requests_). Making improvements to the implementation of the system as needed.  # Implement the _Health Monitoring Algorithm_ for workers of both kinds (Qserv and the Replication system). Integrate this algorithm into the above mentioned _fixed logic Controller_. The initial version of the algorithm will be sending _probe_ requests to both kinds of workers and measure their responses (which must arrive within a reasonable period of time). This may also require to make some adjustments to the Replication system's Messaging Network to respect priorities of these requests. The current implementation has a plain queue. The new one should get a priority queue.  # Finalize and test the fixed-logic replication Controller  # when confident with the functionality, performance and robustness of the Replication system integrate the system with the existing Kubernetes infrastructure"
Answer: 239962.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: "Originally, the functions of performing QA calculations and visualizing the results within {{qa_explorer}} were both contained within the {{QADataset}} object; however, with the completing of DM-13876 and DM-13877, I have externalized the computations to their own task, with results persisted in parquet format and accessible via the butler.  So now, I need to make sure that the visualization part of the code works with this new setup, and to update the demos appropriately."
Answer: 289103.0

User story: "Create usage plots for each of the 3 layers (DEEP, UDEEP, and WIDE) as well as one plot that contains all three layers.  Input the code node-hours in the appropriate table, and comment on the total number of node-hours for each layer.  Create a pie chart or other visual for code node-hours in order to better represent the data."
Answer: 8278.0

User story: "If the prepuller gets stuck, it's possible for pods to hang around in ErrImagePull or ImagePullBackOff and clog up the system.    So we should kill the pods when the timer goes off to shut down the prepuller."
Answer: 10224.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: "Install and test Helm on kubernetes cluster"
Answer: 132835.0

User story: "Duplicate volumes show up and make the spawner unhappy."
Answer: 1158.0

User story: "The signature for the {{validate}} methods in {{validate_drp}} have implicitly changed because, e.g., the {{metrics}} argument is immediately shadowed by {{job.metrics}} in {{runOneFilter}}.  This ticket is to sanitize the doc strings and method signatures to make this more obvious."
Answer: 968111.0

User story: "Add {{ap_verify}} to {{lsst_distrib}}, and add {{ap_pipe}} and its dependencies to {{lsst_apps}}. This includes:    # Moving the packages to the {{lsst}} organization, and assigning admin privileges as described in the [developer guide|https://developer.lsst.io/stack/adding-a-new-package.html]. [Note: this step cannot have an associated pull request].  # Confirming that packages follow Stack conventions (e.g., directory structure).  # Registering any missing packages with {{repos.yaml}}.  # Double-checking that any data package that is an optional dependency of a non-data package is also in {{manifest.remap}}.  # Adding {{ap_verify}} and {{ap_pipe}} to their respective top-level packages' table files."
Answer: 222943.0

User story: "Copy the validate_drp examples to lsst_ci so that they are runnable from lsst_ci.  Put these examples in {{scripts}}, with configuration either in {{etc}} or in {{scripts}}.    Note:  The implementation will leave the examples in validate_drp for now to preserve the Jenkins   build performance.  Removing these from validate_drp will be left for a later ticket."
Answer: 64725.0

User story: "Provide support, fixes and maintenance of configuration within the cluster as it is being developed. Will register incidental work such as helping with deployments, testing, etc,"
Answer: 133944.0

User story: "Understand L1 requirements for the Alert distribution system inside kubernetes cluster"
Answer: 86710.0

User story: "Main ingress point and welcome page with links and information"
Answer: 31559.0

User story: "Provide mechanism to create users and provide roles to DM users for deployments."
Answer: 86709.0

User story: "deploy dashboard and pod/cluster monitoring into kubernetes cluster "
Answer: 163791.0

User story: "Provide configuration files and deploy ingress controller as well as rules for current kubernetes deployment"
Answer: 81.0

User story: "Working on a document that describes the requirements for a production kubernetes cluster"
Answer: 86729.0

User story: "Test and explore federation across clusters for deployment and future clusters deployments, including institutional clusters "
Answer: 86732.0

User story: "Univa has a resource management tool for kubernetes called naviops which provide easy access to policies, , schedulers, management of resources, users, groups and namespaces. It also provide means to allocate projects and deployments. "
Answer: 133963.0

User story: "Add the Lab extension."
Answer: 1398.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: "Re-run the data that [~<USER> processed for the late-2017 LDM-503-3 milestone using a current (May 2018) version of ap_pipe."
Answer: 80592.0

User story: "Suggestion is to hand-construct SLURM commands rather than write a new {{pipe_driver}} since SuperTask will obviate the latter workflow shortly."
Answer: 142879.0

User story: "Run matchedVisitMetrics.py validateDrp.py and reportPerformance.py with the HSC RC2 w_2018_17 outputs from DM-14055.  "
Answer: 3085.0

User story: "- Use variable SQUASH_BOKEH_APPS and same default value for both squash-bokeh and squash deployments    - Add SQUASH_MONITOR_APP and SQUASH_BOKEH_APPS in replace.sh (remove Dockerfile template)    - Link RESTful API to the /apidocs resource in squash    - Add SQUASH_MONITOR_APP to the embed_bokeh_app template context"
Answer: 1294.0

User story: "Ingest LDM-534 and DMTR-51 in Jira LOPS project to evaluate:   * traceability test cases to requirements   * how the the actual DM test approach need to be updated in order to fit in the proposed model"
Answer: 285124.0

User story: "Cover time and effort involved with Gen 3 Middleware meetings, tracking and contributing to discussions in Slack, etc."
Answer: 7.0

User story: "Run   # visitAnalysis   # coaddAnalysis   # colorAnalysis   # compareVisitAnalysis   # compareCoaddAnalysis    with the w_2018_17 RC2 outputs from DM-14055    Use the tickets/DM-13154 branch "
Answer: 3169.0

User story: "Reprocess the HSC RC2 dataset, as defined in DM-11345, using Stack w_2018_18. Steps include {{makeSkyMap.py}}, {{singleFrameDriver.py}}, {{mosaic.py}}, {{skyCorrection.py}}, {{coaddDriver.py}}, and {{multiBandDriver.py}}. "
Answer: 14816.0

User story: "From the Merra-2 analysis, atmospheric transparency as a function of time (415 epochs) is produced for the Photometric Calibration Working Group Data Challenge.    Watch the movie here :    https://confluence.lsstcorp.org/display/DM/Data+Challenge"
Answer: 10146.0

User story: "Work with Cindy to design the SUIT UI to include HSC data"
Answer: 277321.0

User story: "Working with Gregory to design the SUIT UI to include HSC data, both catalog data and images.     Implement the functions to search and display HSC data"
Answer: 277251.0

User story: "Get some HSC sample data to make sure that Firefly can read and display them properly.    The reprocessed HSC data could be accessed from lsst-dev.ncsa.illinois.edu at     /datasets/hsc/repo/rerun/RC/     "
Answer: 103386.0

User story: "Design and implement a module for the {{firefly_client}} Python API for LSST users to easily use Firefly for making plots.   * simplify the connection   * reduce required parameters   * implement convenience function to make dictionary needed by Plotly     "
Answer: 54035.0

User story: "Take the existing AssociationTask functionality and get it running using l1dbproto (rather than SQLite) as a back-end.    (This can run on a standalone system; no need to deploy at LDF.)"
Answer: 86594.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: "When I name a channel starting with a number, I cannot establish communication between the client and the server.  At least nothing shows up in the visualization canvas.  There is no error on the client side."
Answer: 31.0

User story: "Fix broken bits of synpipe that are not related to WCS changes."
Answer: 8659.0

User story: "Remove secondMomentStarselector, per RFC-475, and clean up any tests, etc. that refer to it."
Answer: 4575.0

User story: "There way too many versions and classes that supported old versions of the code, that are no longer viable.  These need to be removed to simplify the module."
Answer: 14223.0

User story: PosixDatastore currently just holds its internal database in memory, rather than on-disk.         My current idea for how to implement this is:     - Add an API for getting a SQLAlchemy engine from SqlRegistry.     - Add a "datastore.db" config entry that can take the same kinds of values as "registry.db", as well as a special value that tells it to get its database from the Registry.     - Make {{StoredFileInfo}} a subclass of something Datastore-generic or otherwise make sure it's introspectable enough to map to a database without hard coding its fields in whatever is doing the mapping.     - Make a really simple ABC that just knows how to dump and retrieve generalized {{StoredFileInfo}} from some kind of database, with subclasses instantiated based on the value of "datastore.db".     - Implement a SQL-based subclass of that ABC.     
Answer: 9221.0

User story: "Use terraform in the CI build for creating the test cluster instead of installing it localy."
Answer: 15693.0

User story: "The endpoint for the SQuaSH RESTful endpoint is hardcoded in the {{validate_drp}} pipeline [here|https://github.com/lsst-sqre/jenkins-dm-jobs/blob/master/pipelines/sqre/validate_drp.groovy#L735].  I think there is a better way to do this so it is easier to keep up if the endpoint changes."
Answer: 224613.0

User story: "DECam data has not been used in the Jenkins {{validate_drp}} job for some time.  This ticket is to get that fixed.    In order to do that, the {{lsst_verify}} specs need to be ported to DECam."
Answer: 11714.0

User story: "Create prompt processing test field from DES (Dark Energy Survey) Supernova field X3. This field is at RA = 36.45 and DEC = -4.6. It has a radius of roughly 1 degree.    On lsst-dev it is located at:  /datasets/des_sn"
Answer: 142727.0

User story: "SSIA."
Answer: 2899.0

User story: "The utility apps (such as catalog listing, image triggering, etc.) must be rebuilt as well as the DAQ Forwarder code."
Answer: 2896.0

User story: "Build means to publish reports as telemetry. Reports may be work done, system warnings, etc."
Answer: 144055.0

User story: "Implement a version of the progressive ACK timer that checks strictly for the one ATS forwarder response; these must be blocking ACKs, so proper ACKs should be identified quickly if received."
Answer: 2905.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 ATS box being sent to Tucson and then on to Chile should restore all necessary services using the proper run level when the machine is rebooted. When one of the system services goes down during runtime, systemctl scripts should take all system services down, purge the message broker queues, and restore the system services in the necessary order. The system then must be tested by forced service failure and by fault injection to confirm that it is robust."
Answer: 29884.0

User story: "Addition of Fault system added some messages that must be verified in the unit test."
Answer: 19985.0

User story: "ATS should inform OCS when a catastrophic problem occurs and enter a Fault state after issuing an error code. Tests must be performed on Fault identification capability. Test series for this issue can be found here:  https://confluence.lsstcorp.org/display/JP/%23110+%28a+through+e%29+Fault+State+Behavioral+Test+Series"
Answer: 29904.0

User story: Build warnings continue to creep into the Developer Guide:    {code}  /Users/<USER>lsst/dm_dev_guide/services/storage.rst:27: SEVERE: Unexpected section title or transition.    ======  /Users/<USER>lsst/dm_dev_guide/services/storage.rst:37: SEVERE: Unexpected section title or transition.    -------------------------------------------------------------------------------------  /Users/<USER>lsst/dm_dev_guide/services/storage.rst:40: WARNING: Block quote ends without a blank line; unexpected unindent.  /Users/<USER>lsst/dm_dev_guide/services/storage.rst:40: SEVERE: Unexpected section title or transition.    --------------------------------------------------------------------------------------  /Users/<USER>lsst/dm_dev_guide/services/storage.rst:43: WARNING: Block quote ends without a blank line; unexpected unindent.  /Users/<USER>lsst/dm_dev_guide/services/storage.rst:43: SEVERE: Unexpected section title or transition.    -------------------------------------------------------------------------------------  looking for now-outdated files... none found  pickling environment... done  checking consistency... /Users/<USER>lsst/dm_dev_guide/services/ldf-resources.rst:: WARNING: document isn't included in any toctree  /Users/<USER>lsst/dm_dev_guide/services/ldf-tickets.rst:: WARNING: document isn't included in any toctree  /Users/<USER>lsst/dm_dev_guide/services/storage.rst:: WARNING: document isn't included in any toctree  done  preparing documents... done  writing output... [100%] work/project-planning  /Users/<USER>lsst/dm_dev_guide/cpp/style.rst:106: WARNING: undefined label: pipelines:source-install-redhat-legacy (if the link has no caption the label must precede a section header)  {code}    This ticket is to fix the existing syntax issues and then prevent future issues by enabling the "error on warnings" aka nitpick mode for Sphinx.
Answer: 95.0

User story: "multiBandDriver.py of the entire HSC PDR1 dataset with w_2018_15  "
Answer: 39993.0

User story: "coaddDriver.py of the entire HSC PDR1 dataset with w_2018_15"
Answer: 39994.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: "mosaic.py of the entire HSC PDR1 dataset with w_2018_15   "
Answer: 39994.0

User story: "skyCorrection.py of the entire HSC PDR1 dataset with w_2018_15  "
Answer: 39995.0

User story: "Per [~<USER>,    _imgserv should parse the authentication token, added to the incoming URL request, and log the user name only. The token is expected to be in [JWT |[https://en.wikipedia.org/wiki/JSON_Web_Token]] format._     "
Answer: 527680.0

User story: Our YAML files are a bit of a mess, and they're very hard to use:   * The defaults for StorageClass and the registry schema are not just nodes in the Butler config tree; there are also special nodes that point to files (e.g. "storageClasses.config") that make it impossible to use the defaults directly, and obfuscate what the real structure ought to be.   * Each of the methods that constructs something from a Config has its own special handling for non-Config arguments (e.g. filenames).   * StorageClassFactory has two public APIs for constructing StorageClasses from Config.   * Because we never validate any of the structures, error messages due to bad configs are very opaque.   * Config files contain references to other Config files that are relative to the current working directory (which is assumed to be DAF_BUTLER_DIR, since that's where tests are run).   * Constructing most important daf_butler objects requires either creating a Config file on disk or a Config object in memory, rather than applying an automatically-located default configuration and overriding with kwargs.    I think it's time to step back and actually design how we want the configuration system to work.
Answer: 33362.0

User story: "Run it and make sure that the default value is sensible.    On another ticket in the future, use this code to see how this value depends on the inputs, _e.g._ flux levels, CCD shape, others, to see how much one fixed value is applicable across cameras/sensors."
Answer: 250610.0

User story: "Update and test the HeaderService codes to run with the python SAL tools classes as separate modules."
Answer: 19702.0

User story: "Migrate the Python SAL classes and tools created as part of the HeaderService. These are used to subscribe to LSST/SAL DDS topics using the ts_sal generated libraries."
Answer: 19704.0

User story: "Write function to capture Camera Geometry Event parameter and translate into standard FITS header parameters, including NAXIS1/NAXIS2 and specification of LCA-13501.    A more importantly make sure that parameters are understood by generating a drawing that we all agree upon."
Answer: 51756.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 idea is to have an isolated environment where users can play with {{lsst.verify}} and squash.     The sandbox will have its own CloudSQL db instance, and will run on a different k8s cluster where production is running.     The instance will be deployed at https://squash-sandbox.lsst.codes    * Simplify the monitor app removing dataset selection, code changes and drill down plots (at least for now)  * Create a mechanism to define which bokeh apps are going to be initialized during deployment of the squash-bokeh and squash services  * Re-work the SQuaSH initial page, the idea is to remove specific text, go straight to the main bokeh app and report statistics about the system on a secondary page  *  No changes in the squash-restful-api should be required  *  Some user documentation will be required, I plan to extend SQR-019 to include an example of {{dispatch_verify}} to the sandbox instance  "
Answer: 10050.0

User story: "The {{lsst.ip.isr.isrFunctions.overscanCorrection}} subtracts the overscan fit from the active image. It should also subtract the same fit from the overscan, allowing downstream processing to operate on the overscan-subtracted overscan (e.g., to measure the noise)."
Answer: 2960.0

User story: "The new deployment includes the following services:    https://squash.lsst.codes  https://squash-restful-api.lsst.codes  https://squash-bokeh.lsst.codes"
Answer: 22.0

User story: `dispatch_verify` is not finding the {{dataset}} env variable in Jenkins.     From `dispatch_verify` help:    {noformat}  **Metadata and environment**    dispatch_verify.py can enrich Verification Job metadata with information  from the environment. In a Jenkins CI execution environment (``--env=ci``) the  following environment variables are consumed:    - ``BUILD_ID`` : ID in the ci system  - ``BUILD_URL``: ci page with information about the build  - ``PRODUCT``: the name of the product built, in this case 'validate_drp'  - ``dataset``: the name of the dataset processed by validate_drp  - ``label`` : the name of the platform where it runs  {noformat}    and here is the current result sent to SQuaSH is:    {noformat}    "env": {        "date": "2018-04-21T03:18:28.473897+00:00",        "ci_id": "1267",        "ci_url": "https://ci.lsst.codes/job/sqre/job/validate_drp/1267/",        "status": 0,        "ci_name": "unknown",        "ci_label": "unknown",        "env_name": "jenkins",        "ci_dataset": "unknown"      }  {noformat}    From that  `BUILD_ID`, `BUILD_URL`, and `PRODUCT` are set in the Jenkins environment, however it looks like `dataset` is not. *Note that this env variable is lower case.*    More info at [https://ci.lsst.codes/job/sqre/job/validate_drp/1267/]  
Answer: 3149.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: "It has been determined that accurate use of Merra-2 data implies integrating the parameters from telescope altitude to top of the atmosphere.    This shall be done for Specific humidity (q) => PWV = sum(deltaPressure *q/g)    both at Hawaii (for comparison with SNFactory measurements)    and CTIO (to feed parameters of PCWG data Challenge)."
Answer: 86448.0

User story: Intermittently, especially on first-time loading a Firefly app, catalog search would fail to load the search results.  The table instead showed a working icon with "Send to background" button.    It easier to reproduce by using incognito or private browsing.  Immediately after loading, do a catalog search.  Increase radius a little to ensure it does not return immediately.    (duplicate of [https://jira.ipac.caltech.edu/browse/IRSA-1709] for record keeping purpose)    *Information from pull request:*    This is an issue when there are multiple connections to the server without a {{usrkey}}(cookie).  The logic is to create a {{usrkey}} when one is not defined. In this scenario, a websocket connection  is given a different usrkey then subsequence calls, causing server to client communication failure.    Solution is to create a {{usrkey}} if one is not found. Also, establish a websocket connection first  before doing anything else. This ensure that the client is getting all of the messages from the  server during startup.    Another notable change in this PR is the reorganization of what we call startup parameter.  In the old way, we define a firefly.app object which contains properties used during startup(bootstrap).  firefly.app may contains an 'options' property which is used to customize a variety of Firefly's behaviors.  Also, there are places where 'options' are defined directly under firefly, i.e. '{{firefly.options}}'    In this PR, bootstrap will take 2 parameters; props and options.   * props(AppProps) is defined as firefly.app   * options(FireflyOptions) is defined as firefly.options    This will be used consistently everywhere, API as well as the application HTML page.    The defaults for these 2 parameters are defined in {{Firefly.js}}. It should also provides basic documentation on its usage.. (just skeleton, to be filled in later)  There are 2 places where the defaults can be overridden; at the application entry point or at window.firefly.  Properties defined in window.firefly will override entry point, and what's defined in entry point will override Firefly.js's defaults.  Parameters are deep(recursively) merged, unless the value is an array, in which case, it will replace.    Also in this PR:   * remove old GWT code   * refactor Table code to use a generic 'Send to background' panel    Changes are in firefly, ife, and suit under the same branch name.
Answer: 1094843.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 ran multiBandDriver.py on HSC-R 9813 3,4 to determine if any cModel configuration parameters can/should be changed to improve the running time and/or best-fit model parameters. My conclusions for the tested parameters are:        initial.nComponents (default 3): For 2, initial fits run in 0.67x the time, but the exp/dev fits run more slowly, so the total fit time is 0.94x. Initial fits are slightly worse on average (with large scatter) and a sizeable fraction of the dev/exp fits are significantly worse (deltalnP < -10).           For nComponents=6, the initial fitting time is more than twice as long, with modest increases in the exp/dev lnP (<1 for most galaxies, with scatter).           Recommendation: leave it at 3 or lower to 2.       initial.optimizer.gradientThreshold (default 1e-2): 1e-3 runs very slightly faster than default and very slightly improves fits. 1e-1 is slightly slower and also results in slightly worse initial/final fits.           Recommendation: lower to 1e-3.       initial.optimizer.maxInnerIterations (default 20): Zero impact on fits, running time for 8 is virtually identical; 50 is 1% slower.           Recommendation: leave at 20.       initial.optimizer.noSR1Term (default False): True radically changes fitting times by factors of (0.33, 4.37, 4.98)x for (initial, exp, dev) i.e. the initial fit is faster but the subsequent exp/dev are much slower.           Confusingly, the initial fits are better on average, whereas the final dev/exp are worse - this may warrant follow-up. Many of the very slow fits have faint PSF mags and may be pathological cases.           Recommendation: leave as False.       region.nFitRadiiMax (default 3): Surprisingly, nfitrad=2 initial fits are 0.5% slower than the default, whereas nfitrad=5 is 2% faster. However, the total fitting time scales by a factor of (0.86, 1.38) for the smaller/larger size.           Smaller fitting regions naturally have larger likelihoods, but I can't make a meaningful comparison between likelihoods - presumably the smaller region fits better in the common are and worse outside.            Recommendation: leave as is pending further investigation.    One common feature is that there is a non-negligible fraction of objects (usually with faint mag_psf) with very small differences in initial fit likelihood but large ones in the dev/exp fit, which should not occur frequently.    The quoted figures can be generated by the notebook created in DM-14118 (lsst-dev:/home/<USER>src/mine/taranu_lsst/cModelConfigs.ipynb)."
Answer: 100400.0

User story: "There are a number of fgcm and transmission curve-related datasets in obs_base's {{policy/datasets.yaml}} and {{policy/exposures.yaml}} that need descriptions. See the descriptions that were added in DM-13756 for examples: a sentence or two describing what the dataset is and what might read/write it."
Answer: 15458.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: "There are a number of dcr-related datasets in obs_base's {{policy/datasets.yaml}} and {{policy/exposures.yaml}} that need descriptions. See the descriptions that were added in DM-13756 for examples: a sentence or two describing what the dataset is and what might read/write it."
Answer: 130907.0

User story: "I examined the distribution of cModel running times for HSC-R 9813 3,4. Two things are apparent - with default settings, some faint sources (mag_psf > 26) take a long time to fit (>1 min); also, changing parameters like the number of initial components or the fit algorithm can exacerbate this problem.    The attached plots can be generated by the notebook created in DM-14118 (lsst-dev:/home/<USER>src/mine/taranu_lsst/cModelConfigs.ipynb). I have also put it up on [https://github.com/lsst-dm/modelling_research] (see test_lsst_cmodel.py and jupyternotebooks/lsst_cmodel_configs.py/.ipynb), which supersedes the local copy on lsst-dev."
Answer: 80480.0

User story: "Perform overall facility planning and high-level engineering. This typically includes emergent work at the management, steering and planning level."
Answer: 111060.0

User story: "Perform overall facility planning and high-level engineering. This typically includes emergent work at the management, steering and planning level."
Answer: 86652.0

User story: "Perform overall facility planning and high-level engineering. This typically includes emergent work at the management, steering and planning level."
Answer: 24409.0

User story: "Per discussion with [~<USER> yesterday, the following action items are needed in the short term meet dax's CI needs:    * rename jenkins {{qserv/}} folders -> {{dax/}}  * setup new dax equiv of {{stack-os-matrix}} that;  {noformat}      - does not include osx      - does not include centos 6      - includes a clang/linux config  {noformat}  * new dax release pipeline that publishes eupspkg and moves only {{qserv-dev}}    forward  * stop applying {{w_201X_XX}} format tags to dax packages (unused) -- this means splitting dax out of the nightly,weekly science-pipeline releases  * stop updating {{qserv_latest}} tag (dead)  * support TBD jenkins integration builds triggered by github push"
Answer: 20455.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: After a catalog is searched, the positions are overplotted on a a coverage image. In the past, we could only choose between a variety of FITS cutouts and an Aitoff projection. In the current version of Firefly, HiPS maps have been added to the mix. Here are some changes that should be made with respect to that implementation:   # The default small scale coverage image source is WISE Band 4. This should be changed to 2MASS K-band.   # The FITS image label should include the mission, band, and FOV. (Right now it just says "Coverage".)   # The default medium scale coverage image source is a DSS color HiPS map. This should be changed to a 2MASS color HiPS map.   # The default all-sky coverage map source is DIRBE. This should be changed to a color 2MASS Aitoff map.   # There should be no automatic transition with zooming-, unless the user checks a new "Auto" checkbox.-   # The grey area above the coverage image should have three buttons: "FITS", "HiPS", "Aitoff". The one that is currently being displayed should be highlighted.   # Coordinate system frames choice of “EQ J2000” and “Galactic” only appears when “HiPS” data is displayed.   # Coordinate system frames choice of “EQ J2000” and “Galactic” only appears when “HiPS” data is displayed.   # (Update) The tooltips for each of these three buttons should be:   ** FITS: "Scientific pixel data over limited regions"   ** HiPS: "All-sky multi-resolution picture with spherical projection"   ** Aitoff: "All-Sky single-resolution picture with Aitoff projection"    Update: I've updated the mock-up of the gator coverage panel to get rid of the Auto checkbox, in consultation with [~<USER>. (This is because we don't have Auto implemented between HiPS<–>Aitoff, yet. We will solve this problem in the future by providing Aitoff projections in HiPS format.)
Answer: 26982.0

User story: "Find a way to not have to redo the JupyterLab build on each startup."
Answer: 5765.0

User story: The photometry failures may be related to not having"appropriate" reference stars. I should try a few other source selectors, starting with the {{flaggedStarSelector}} (which uses bright PSF sources), to see if they are a better match than the astrometrySourceSelector.    I'll want to be able to count measuredStars (i.e. DM-14153) in order to tell whether the new source selector is picking enough sources to be useful.
Answer: 36071.0