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: "While doing some testing, we found out that `scp` performs better in some use cases rather than `bbcp`. Currently `bbcp` options are implemented in the code file. That should be moved out so that if anyone has the will to change to `scp` or any other `cp`, they can use configuration file to change."
Answer: 1534.0

User story: "The settingsApplied event is getting moved to generics.  Remove it from ATArchiver, PromptProcessing and MTArchiver."
Answer: 12489.0

User story: Please add the following to the ospl.xml configuration file in the {{<DDSI2Service name="ddsi2">}} section:  {code}    <Discovery>       <ParticipantIndex>none</ParticipantIndex>    </Discovery>  {code}    so the ScriptQueue can load more than 9 scripts at one time.
Answer: 38360.0

User story: "Documentation."
Answer: 220031.0

User story: "Unit Tests and Jenkinsfile."
Answer: 214333.0

User story: "Continuing testing the M1M3 Cell according Jira test plan for it."
Answer: 14027.0

User story: "Ticket to track work for deployment on Tucson Test Stand. "
Answer: 12675.0

User story: Add a new tag to SALSubsystems.xml to allow the selection of which languages are required to be supported per CSC.     Values allowed include "c++,python, idl,java,labview"  
Answer: 54855.0

User story: "Update the services files for the ATArchiver and ArchiveController as part of the dm_ATArchiver deployment."
Answer: 1426.0

User story: "Make the helm chart for TAP be able to be used for not only GKE, but -int and -stable, with all the trimmings."
Answer: 10214.0

User story: "If we use JWT at GKE too we can just use the same scheme for Argo authentication."
Answer: 19933.0

User story: "We can factor a lot of the stuff out of the spawner so we can use it for workflow too."
Answer: 72061.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: People present:    * <USER> Merlin-Fisher-Levine, Andy Rasmussen, <USER> <USER> Andrés Plazas     Slack channel (private): #dm-cam-concordance    Notes (by Aaron) related to code comparison between EOTest and DM tools:     1) Using BOT run 6806D compare Master Bias Frames between eotest and DM   2) Using BOT run 6806D compare identification of dark and bright defects between eotest and DM algorithms.  Note that differences are expected due to differences in the cut values and absolute vs. nsigma criterion   3) Using either the more limited data in 6806D or preferably the much more extensive data in 6846D (acquisition was run 6790D) compare Photodiode vs. ADU linearity curves, and PTC curves between eotest and DM    Plan to meet again in 2-3 weeks time to review first results.   - Other topics discussed included dust particles and their effects on the CCD images. From an email sent by Seth:     " The main topic of the Camera Technical Meeting on Tuesday was whether to continue to clean 'dust' from the science raft sensor surfaces before they are integrated into the cryostat (slides here [https://confluence.slac.stanford.edu/display/LSSTCAM/CTM?preview=/132226328/266865616/sensor_cleaning_CTM_191023.pdf]).  In the discussion, Andy pointed out that some of the image defects that we'll see in the LSST image data are not just related to the obscuration of pixels by dust on the sensor surfaces but also scattering of light by the dust, which especially for a beam as fast as LSST's could make the region of influence of a dust speck much larger than its physical area.  We are probably seeing something like that in the BOT EO test data, with the flat illuminator projector (e.g., in slide 16). "
Answer: 66652.0

User story: "          Resources:     https://confluence.lsstcorp.org/display/DM/Live+demo%3A+test+ingest+of+a+subset+of+one+track+of+the+HSC+Object+catalog    DM-21810      "
Answer: 262171.0

User story: "This ticket records that the lsst-demo server SSL certificate was renewed by [~<USER>."
Answer: 5.0

User story: "In order to implement the changes ratified in the [settingsApplied|https://confluence.lsstcorp.org/display/LSSTCOM/Commissioning+Activities+2019-05-14+Meeting+notes#CommissioningActivities2019-05-14Meetingnotes-settingsApplied] discussion, the similarly named CSC specific event needs to be renamed or removed. Please see the generic event attributes to make that decision."
Answer: 54566.0

User story: "In order to implement the changes ratified in the [settingsApplied|https://confluence.lsstcorp.org/display/LSSTCOM/Commissioning+Activities+2019-05-14+Meeting+notes#CommissioningActivities2019-05-14Meetingnotes-settingsApplied] discussion, the similarly named CSC specific event needs to be renamed or removed. Please see the generic event attributes to make that decision.    This is a child of CAP-365"
Answer: 251.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: "In order to implement the changes ratified in the [settingsApplied|https://confluence.lsstcorp.org/display/LSSTCOM/Commissioning+Activities+2019-05-14+Meeting+notes#CommissioningActivities2019-05-14Meetingnotes-settingsApplied] discussion, the similarly named CSC specific event needs to be renamed or removed. Please see the generic event attributes to make that decision.    This is a child of CAP-357"
Answer: 258.0

User story: "Several folks have reported transient failures to build obs_lsst in w_2019_43. These are hard to catch, because the immediate response is usually to retry the build... which succeeds, and wipes out the log of the failure in the process. However, I think I caught it in action. The punchline is:    {code}  >           raise ValueError(INTERPOLATE_ERROR.format(auto_max_age))  E           ValueError: interpolating from IERS_Auto using predictive values that are more  E           than 30.0 days old.  E             E           Normally you should not see this error because this class  E           automatically downloads the latest IERS-A table.  Perhaps you are  E           offline?  If you understand what you are doing then this error can be  E           suppressed by setting the auto_max_age configuration variable to  E           ``None``:  E             E             from astropy.utils.iers import conf  E             conf.auto_max_age = None    ../../../../../../python/miniconda3-4.5.12/envs/lsst-scipipe/lib/python3.7/site-packages/astropy/utils/iers/iers.py:679: ValueError  {code}    Full log is attached."
Answer: 15376.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 Jenkins nightly and weekly release builds are failing to build binary packages for macOS (although Linux is fine).    For example, look at [nightly #792|https://ci.lsst.codes/blue/organizations/jenkins/release%2Fnightly-release/detail/nightly-release/792/pipeline] or [weekly #256|https://ci.lsst.codes/blue/organizations/jenkins/release%2Fweekly-release/detail/weekly-release/256/pipeline/176].    In both cases, the pipeline superficially appears to have completed successfully. However, in fact the “build eups tarballs” stage failed on {{osx-10.14.clang-1000.10.44.4.miniconda3-4.5.12-f032070}} with the (repeated) message:  {code}  Scheduling project: release » tarball  Starting building: release » tarball #4830  release » tarball #4830 completed with status FAILURE (propagate: false to ignore)  {code}  then eventually  {code}  giving up on build but suppressing error  {code}    This error is due to a failure to find a dylib in the astshim package:  {code}  ____________________ ERROR collecting tests/test_append.py _____________________  ImportError while importing test module '/Users/square/j/ws/release/tarball/osx/10.9/clang-1000.10.44.4/miniconda3-4.5.12-f032070/build/stack/miniconda3-4.5.12-f032070/EupsBuildDir/DarwinX86/astshim-18.0.0+6/astshim-18.0.0+6/tests/test_append.py'.  Hint: make sure your test modules/packages have valid Python names.  Traceback:  tests/test_append.py:5: in <module>      from astshim import Frame, SkyFrame, UnitMap, FrameSet, append  python/astshim/__init__.py:26: in <module>      from .base import *  E   ImportError: dlopen(/Users/square/j/ws/release/tarball/osx/10.9/clang-1000.10.44.4/miniconda3-4.5.12-f032070/build/stack/miniconda3-4.5.12-f032070/EupsBuildDir/DarwinX86/astshim-18.0.0+6/astshim-18.0.0+6/python/astshim/base.so, 2): Library not loaded: libastshim.dylib  E     Referenced from: /Users/square/j/ws/release/tarball/osx/10.9/clang-1000.10.44.4/miniconda3-4.5.12-f032070/build/stack/miniconda3-4.5.12-f032070/EupsBuildDir/DarwinX86/astshim-18.0.0+6/astshim-18.0.0+6/python/astshim/base.so  E     Reason: image not found  {code}    However:    * I am able to build astshim, using the same {{eups distrib}} incantation as Jenkins, on my macOS laptop with no problems;  * Jenkins has itself built this version of astshim in an equivalent Conda environment as part of the stack-os-matrix — this failure appears to be peculiar to the release pipelines.    "
Answer: 19897.0

User story: "DM-21967 allowed for fitting COSMOS HST images of butler catalog sources. This ticket is specifically to compare fits of isolated galaxies in COSMOS using HSC-[IZ] vs HST-F814W, which cover similar wavelength ranges."
Answer: 136505.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 effort is create a Confluence page that outlines the steps needed to complete the end-to-end automated build/deploy/test infrastructure.  It will include estimates of the time and resources needed.  At the end, this will feed a Jira Epic and its Tasks that will track this effort.    After the initial page is created, I will meet with stakeholders ([~<USER>, [~<USER>, [~<USER>, [~<USER>, etc) to get by-in and approval of the plan."
Answer: 15828.0

User story: "An update to DMTN 025 is made for the adaptation of BPS to use HTCondor & HTCondor DAGMan."
Answer: 2420.0

User story: "Two ts_ATMCSSimulator unit tests are broken:  * test_csc.py test_initial_info is broken because of the addition of the {{softwareVersions}} generic event.  * test_csc.py test_set_instrument_port has an intermittent failure because the CSC sometimes uses tracking instead of slewing to move M3.    The first test will start working if and when salobj supports {{softwareVersion}} but meanwhile I can disable that.    The best way to fix the second test is to use the point to point actuator from ts_simactuators for M3 rotation, but for now there is an easy fix to prevent tracking."
Answer: 2765.0

User story: "Package a new version of CFITSIO. This will definitely cause some tests to fail and FITS serialization code in afw (and other packages) may need to be updated, especially metadata packages."
Answer: 296594.0

User story: "Deploy {{ts_xml 4.4.0}} and {{ts_sal 3.10.0}} in Tucson"
Answer: 1487.0

User story: "remove debugging print statements"
Answer: 265209.0

User story: "Create admin privileges on laptop to be able to install any Labview packages I need."
Answer: 91.0

User story: "This task will cover my time spent in Tekniker. All notes, fact finding, and documentation for this visit will be recorded on this page here [https://confluence.lsstcorp.org/pages/viewpage.action?pageId=120783022]"
Answer: 19888.0

User story: "NCSA and Tucson test-stands use different sets of configuration files for dm_forwarder. So, two configuration files are to be put in place under dm_iip_deploy/etc/config/ with folder names ncsa and tucson."
Answer: 2968.0

User story: "The round-trip test of the flux storage and retrieval (and conversion to ab magnitudes) has an inconsistency between 32 and 64 bit floats, leading to round-off errors.  Fix this inconsistency, which for some reason seems to be a problem with numpy 1.17 and was fine with numpy 1.16."
Answer: 1323.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 looks like the formatter used to read raw LSST images in Gen3 ([https://github.com/lsst/obs_lsst/blob/master/python/lsst/obs/lsst/gen3/rawFormatter.py#L41|https://github.com/lsst/obs_lsst/blob/master/python/lsst/obs/lsst/gen3/rawFormatter.py#L41)]) is missing logic that adjusts amplifier positions from (0, 0) to the appropriate positions on the untrimmed-but-assembled image - note that the base class just calls {{getDetector}} when constructing the full exposure ([https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/fitsRawFormatterBase.py#L344]).  That breaks ISR in Gen3, as [~<USER> recently discovered.    But the adjustment that the Gen2 I/O logic makes isn't really okay either - {{Detector}} is supposed to be immutable, and it's only due to a loophole that we're closing in DM-18610 that this works at all.  Much more importantly, the whole point of assembling raws behind {{butler.get}} is to make it so the caller doesn't care that the on-disk amplifier images are per-HDU rather than assembled - but this is exposed by the fact that the amplifiers one gets from {{butler.get("camera")}} do not have the right offsets, because those don't go through assembly.    I think the right fix so to have {{Amplifier}} bboxes in obs_lsst _always_ use the nonzero post-assembly positions, so we wouldn't have to change the {{Detector}} at all.  The fact that the amplifier images are per-HDU (and hence have a bbox with (0, 0) origin) on disk is supposed to be completely invisible to the user, and that means it shouldn't ever been seen in the camera geometry.  If we need to record the fact that the on-disk images are different, we should put that somewhere else in the camera geometry.    So while we could work around this problem now by reimplementing {{readFull}} in obs_lsst (probably with some code duplication) to mimic the current Gen2 logic, I'm hoping [~<USER> may already be fixing this on DM-18610 by changing the Gen2 logic instead.
Answer: 25687.0

User story: "Sample configuration file for forwarder is added. Along with that, there were some code clean up."
Answer: 5492.0

User story: "fopen() returns null pointer when file cannot be created. The nullptr check wasn't in the code and it was causing segfault."
Answer: 3892.0

User story: "It will be useful for testing to ap_association and dax_ppdb to have more than one filter available for the ap_verify dataset. Currently preventing this is that there are no templates available for the r band data that is part of hits2015. This ticket will create said templates."
Answer: 289675.0

User story: "The Docker configuration for the {{ATHeaderService}} is now defined in the repo  https://github.com/lsst-dm/sal_Dockerfiles    Moreover, the {{ATHeaderService}} now can run as a service on a docker container."
Answer: 5835.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: "Create a simple set of code that simulates loading scripts and can be used to quickly try different solutions to speed up script loading.    This continues the work started in DM-21175 to speed up script loading.  "
Answer: 7266.0

User story: "Deploy {{ts_xml 4.4.0}} and {{ts_sal 3.10.0}} on the NCSA Test Stand and create docker images for {{ATHeaderService}}"
Answer: 23.0

User story: "A new version of {{ts_xml 4.4.0}} has been released. This new version rpms/repo and the accompanying new meta-data need to be tested at the NCSA Test Stand. The test should include {{ATCamera}}, {{ATArchiver}} and {{ATHeaderService}}."
Answer: 3.0

User story: "Please add boto3 and moto Python packages to the development Docker image.    boto3 https://boto3.amazonaws.com/v1/documentation/api/latest/index.html is used to send files to S3 buckets, which we plan to do for the LFA. moto http://docs.getmoto.org/en/latest/ is used to unit test boto3 code."
Answer: 6120.0

User story: "DM-21802 implemented extracting and fitting COSMOS HST F814W cutouts of galaxies for sources in Butler catalogs (e.g. HSC UltraDeep) without having to rely on the GalSim catalogs as in DM-15354. DM-21887 determined that it would be possible but not particularly easy to determine the PSF by fitting stars, so this ticket will implement fitting the TinyTim-based model PSF for the nearest source in the GalSim catalog as an interim solution."
Answer: 65255.0

User story: "During the processing of scarlet for the mini deblending sprint it became painfully obvious that scarlet is a memory hog and will need to have the fat trimmed in order to have a realistic chance of deblending full LSST patches. The biggest source of wasted memory is in the models themselves, where each object has a model that takes up the entire rectangular bounding box for a blend, meaning memory usage is ~ K*B*N, where K is the number of sources, B is the number of bands, and N is the number of pixels. If we instead put each source in a bounding box then this should scale as roughly K*B, since the number of pixels (ie the size of the blend) will be a much smaller constant factor for large blends (except for images where a large blend is caused by a very large extended galaxy).    Currently [~<USER> is completing a branch that introduces a significant improvement to the optimization algorithm in scarlet, namely it implements a version of the ADAM adaptive gradients that uses proximal operators like the ones required by scarlet. His preliminary testing shows that this algorithm both converges faster and to a better fit than the current proximal gradient method used in scarlet. Once this branch has been merged this ticket will  commence to introduce bounding boxes around sources to make scarlet more memory efficient."
Answer: 65243.0

User story: "This ticket involves tracking down blends that scarlet failed to deblend and attempting to identify causes that can be fixed in new tickets."
Answer: 78227.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 just a ticket to estimate the amount of time spent during the deblending sprint assisting Sophie with running the updated {{meas_extensions_scarlet}}, outside of any time included in other tickets that actually fixed bugs, but including time discussing plots, and data visualizations for work that was not done directly by me."
Answer: 78231.0

User story: "dm_forwarder should support file_transfer status of fitsfile if errors occur. That information is captured by processing_status topic of SAL message."
Answer: 8006.0

User story: "Create systemd service for dm_forwarder component."
Answer: 597.0

User story: "This task will update the middleware code to follow the updated xml of hexapod and rotator. Russell and Rob planned to update it based on the test in SLAC and naming convention. And this will break the middleware code definitely. Therefore, the update of middleware is necessary.    This is a followed-up task of:    [DM-21699|https://jira.lsstcorp.org/browse/DM-21699], [DM-20969|https://jira.lsstcorp.org/browse/DM-20969], and [DM-20971|https://jira.lsstcorp.org/browse/DM-20971]."
Answer: 79986.0

User story: "This task will ship the management PC and diagnostic PC (ThinkPad) of hexapod and rotator to Chile.    The story point of this task contains the work in DM-21959."
Answer: 8059.0

User story: "This task will test the middleware code with SAL 4.0. The previous test in SLAC is SAL 3.10.0. T&S team plans to use the SAL 4.0 in the integration test in Dec."
Answer: 6546.0

User story: "This task will upgrade the M2 control system from LabVIEW 2016 to 2018. This task will try to fix some minor bugs as well.    This is a follow-up task of [DM-21158|https://jira.lsstcorp.org/browse/DM-21158]."
Answer: 20912.0

User story: "Update packages that have simulated actuators to use ts_simactuators. These include:    * ts_ATDome  * ts_ATMCSSImulator"
Answer: 78661.0

User story: "To close out DM-19473, we need a Community post announcing the new refcat so people can use it. I will write that post now and declare the epic finished."
Answer: 70.0

User story: "Recalculate the percentage of sky that will be covered by templates given the reduction in SV commissioning surveys. Provide a clear estimate on how much of the sky could be covered with commissioning templates given changes to the commissioning observing program. Update DMTN-107 with new estimates     "
Answer: 71902.0

User story: "Support testing my rotator CSC code on the rotator at SLAC.    This testing was originally scheduled for Monday, October 28 but was moved to November 1.  "
Answer: 27392.0

User story: "In order to test the performance of fgcmcal calibrations, validate_drp needs to be updated to read fgcmcal and fgcmcal_tract photoCalib files if configured to do so.    Additionally, post metrics for running fgcmcal on RC2."
Answer: 78907.0

User story: "slides and stuff"
Answer: 15754.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: "Write code inspector scripts to parse CSC code in C++, Java, Python, LabVIEW  to determine interdependencies, and generate RPM dependency list for use  with CSC RPM builders"
Answer: 146639.0

User story: "Create a {{Task}} whose run method includes all of the logic in {{ApPipeTask.runAssociation}} aside from Butler I/O. The new subtask should not take ownership of {{ApPipeTask.ppdb}}, as that will be an unnecessary breaking change to the configs. (The command-line interface will be different in Gen 3 anyway, and it's better to have two UI versions than three.)    This should probably be done after DM-21877, so it can use the same approach to signal completion of PPDB writes to downstream PipelineTasks."
Answer: 8980.0

User story: "Update the RPM generation for the SAL runtimes to be compatible with CentOS 8"
Answer: 283843.0

User story: "Update the SAL SDK for CentOS 8, build and test CSC's against it for  C++, Python (pybind11), Java, LabVIEW"
Answer: 282300.0

User story: "Rebuild the latest OpenSplice community edition from source , include  Python3.7/Cython based build of the native pydds bindings"
Answer: 288189.0

User story: "This is a mostly-umbrella ticket for getting all current Gen2 ap_pipe functionality working in Gen3. The goal is being able to run AP on HiTS 2015 using the {{CmdLineActivator}}. It includes:  * creating scripts that ingest HiTS test data into a Gen3 repository (DM-21862)  * conversion of all remaining {{ApPipeTask}} subtasks to Gen 3 (DM-21874, DM-21886)  * creation of a YAML file configuring the pipeline (1 SP on this ticket)    {{ApPipeTask}} has a lot of code for handling the case of calexp difference imaging templates. By general agreement within the AP and Middleware groups, we will *not* be porting this functionality to Gen 3 (see also DM-21874), and will reimplement it from scratch should we need it after migration."
Answer: 350232.0

User story: "Forwarder should publish associated_ack with reply_queue params so that in the future, when the forwarder rabbitmq queue becomes dynamic, this information will serve the CSC with which queue to talk to."
Answer: 175.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: "Currently, running a {{MetricTask}} may either return a {{Measurement}}, return {{None}}, or raise an exception (preferably {{MetricComputationError}}). More details can be found [in the documentation|https://pipelines.lsst.io/v/v18_1_0/modules/lsst.verify/tasks/lsst.verify.gen2tasks.MetricTask.html#error-handling].    [~<USER>, in the DM-21885 discussion, said:  bq. I think we'll want to take a look at the expected-failure modes for {{MetricTasks}} you refer to in #3 as use cases for {{PipelineTasks}} in general, and define some rules that would allow them to work with generic activators.  We've done a tiny bit of work in that area so far, but have long known that we need more sophistication in classifying and handling failures.    Depending on how much these rules change the existing behavior, we may need to change the implementation of every concrete {{MetricTask}}, so story points are hard to estimate."
Answer: 449705.0

User story: "Investigate with local NCSA admins the authentication issues we're seeing that slow down initial contact with servers.    There's a slow down when the connections are first made, but later connections do not slow down.  This has impacted performance of file transfers.    (This relates to an NCSA internal ticket, which can't be linked here: LSST-2628)"
Answer: 193197.0

User story: "Create a technical manual for the 2019-era Portal Aspect.    It will combine a basic concept of operations with build, deployment, and maintenance information."
Answer: 362100.0

User story: "Try out DFT space operations to understand:   * How to properly do convolution in DFT space in image and PSF kernel relation   * Padding, borders, translation of originals   * Numeric optimization of DFT, IDFT transformations by shifting significant values into the high-frequency region.   * Demonstrate a kernel inversion (deconvolution) operation, prototype how to do this in the decorrelation afterburner   * [~<USER>'s hint: Check whether the above works for odd size FFT calls because odd size handling in DFT may be implementation dependent.    Write this in a jupyter notebook."
Answer: 57624.0

User story: "Once all the individual components support Gen 3, add a command-line option to {{ap_verify.py}} that ingests into a Gen 3 repository, then runs the AP pipeline and any metric tasks as Gen 3 products. Design the UI so that Gen 3 can naturally become the default behavior as Gen 2 is phased out."
Answer: 433280.0

User story: "Argo project GH homepage README has a misleading link."
Answer: 8445.0

User story: "The DCR template generation code inherits from {{AssembleCoaddTask}} which has already been converted to a PipelineTask, so it should hopefully not be too much extra work to update {{DcrAssembleCoaddTask}}. I expect the majority of the work will involve adding a {{runQuantum}} method and a {{DcrAssembleCoaddConnections}} class."
Answer: 164284.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: "{{lsst.ap.verify.DatasetIngestTask}} is responsible for ingesting an {{ap_verify}} dataset into a Gen 2 repository. Create a second task that starts with the same inputs, but creates a Gen 3 repository. Provide a (command-line?) option in {{ingest_dataset.py}} that lets users choose between the two.    Note that the current [dataset format|https://pipelines.lsst.io/modules/lsst.ap.verify/datasets-creation.html] includes a stub Gen 2 repo (possibly redundant in Gen 3) and a Gen 2 templates repo (must be updated or replaced). Changes to this format are within scope of the ticket.    Some overlap with DM-21862, which wants to use HiTS to run single-frame processing."
Answer: 381717.0

User story: "Create the TN and put the script in place  to generate the tables from the google sheet."
Answer: 38480.0

User story: "If dockerhub returns an error when the hub is trying to walk the tags, then the hub will get stuck.  It thinks that it is still scanning and holds the lock, which just makes incoming requests timeout.  Stack trace coming up shortly."
Answer: 8505.0

User story: "{{lsst.verify.tasks.PpdbMetricTask}} must take a single database as input, but may compute a more fine-grained metric. Therefore, its {{run}} method takes the output data ID as a keyword argument. Create a custom {{runQuantum}} method to support this argument; it should be identical to {{PipelineTask.runQuantum}} except for the extra keyword."
Answer: 77816.0

User story: "{{MetricTask}} is a Gen 2 task that provides a non-dataref abstract {{run}} method, as well as some functionality needed to read Gen 3 input specifications without access to a Gen 3 repository. As such, it should be possible to add {{PipelineTask}} functionality using the standard procedure developed for {{CmdLineTask}}.    Story points are a guess; I'm not clear what needs to be done besides adding a {{Connections}} class for the {{Measurement}} output. {{MetricTask}} should use the default {{runQuantum}} method, although at least one subclass will need to override it (DM-21912).    The existing Gen 2 methods like {{MetricTask.areInputDatasetsScalar}} should _not_ be deprecated until Gen 2 itself is."
Answer: 72158.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 migration plan alluded to in [DMTN-098|https://dmtn-098.lsst.io/], and researched in DM-16503, involved creating separate Gen 2 and Gen 3 {{MetricTasks}}. This plan was motivated by the assumption that metrics would be in wide use by the time of the migration, making writing a class adapter for each and every metric impractical. However, {{MetricTask}} has seen limited uptake, making the careful approach unnecessary.    The new plan is to follow the process the Middleware group has been using, and retrofit Gen 3 functionality onto {{MetricTask}} directly. The only loose end is the current use of {{gen2tasks.MetricTask}}.    Move {{gen2tasks.MetricTask}} to {{tasks.MetricTask}}, keeping the old name as a deprecated alias (much as we did when we created the new {{geom}} package from {{afw.geom}}). Update known MetricTasks to use the new name immediately."
Answer: 38842.0

User story: "contact speaks and put agenda together (even if I am not attending !)"
Answer: 17211.0

User story: "We have the lsst-sqre/chart repo, which is a helm repo, and we have a copy in the nublado repo, which is where I put it before I did the rest of the work.  So we should delete the one in nublado.  The helm chart one is the one people will use because that's where the packages are."
Answer: 282.0

User story: Helm chart for nublado needs to be updated, right now you can't spawn a lab because of this error about dask RBAC roles:       {code}  Error: (403) Reason: error HTTP response headers: HTTPHeaderDict(\{'Audit-Id': '4831b6fb-55ef-4856-ad53-9073f204b8b8', 'Content-Type': 'application/json', 'Date': 'Wed, 23 Oct 2019 18:45:47 GMT', 'Content-Length': '526'}) HTTP response body: \{"kind":"Status","apiVersion":"v1","metadata":\{},"status":"Failure","message":"roles.rbac.authorization.k8s.io \"dask\" is forbidden: user \"system:serviceaccount:nublado:nublado-hub\" (groups=[\"system:serviceaccounts\" \"system:serviceaccounts:nublado\" \"system:authenticated\"]) is attempting to grant RBAC permissions not currently held:\n\{APIGroups:[\"\"], Resources:[\"pods/log\"], Verbs:[\"get\" \"list\"]}","reason":"Forbidden","details":\{"name":"dask","group":"rbac.authorization.k8s.io","kind":"roles"},"code":403}  {code}       Looks like there was a change here that is required:    [https://github.com/lsst-sqre/nublado/commit/80da1e9b63767fc367bcf5d11e06aa336f874287]
Answer: 8800.0

User story: "Testing the new reviewer email alert. "
Answer: 158722.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: "We'll have use cases (at least from HSC, but probably for LSST as well) for being able to include dimension metadata fields that aren't themselves the primary keys of other dimensions (e.g. {{detector.name_within_raft}}).  We may also (after DM-21773) want to be able to use per-dataset metadata fields as well.    This of course has implications for our ability to validate that templates with generate unique filenames, but I _think_ we already have cases where we trust the user because it's not practical for the system to be able to verify it.  If not, I think we'll want that here."
Answer: 41861.0

User story: "Pytest is provided by the Conda environment. But we're also carrying an (older) version as an EUPS package, and it's causing problems. Drop it."
Answer: 1592.0

User story: "As described in [sqr-034.lsst.io |http://sqr-034.lsst.io] we'll have EFD data replication from the Summit and test stands to the LDF. The natural way to implement that is by using the Confluent Replicator source connector.    https://docs.confluent.io/current/connect/kafka-connect-replicator/index.html    In this ticket, we'll test topic replication from the Tucson test stand and from the Summit EFDs (source) to the  EFD instance deployed at Google Cloud (destination)    We'll also need to test schema migration.  In our architecture we deploy the Kafka Schema Registry in both the source and destination clusters.     https://docs.confluent.io/current/schema-registry/multidc.html#schemaregistry-mirroring  "
Answer: 13319.0

User story: "It is clear from DM-21746 that a mechanism is needed for testing conda env changes before merging to master.  In the past, this was done by standing up a complete jenkins test env but this isn't practical for regular development."
Answer: 228.0

User story: "Implement a PipelineTask executor that submits to all batch systems currently supported by ctrl_pool and uses MPI to distribute Quantum executions to worker nodes as the QuantumGraph is walked in dependency order.    I'm hoping the first version of this can get away with assuming all Quanta require the same number of cores and same amount of memory, as that will make things substantially easier (though that would require running jointcal and FGCM separately, and hence bifurcating the DRP pipeline around them).    A moderately mature Batch Production Service with features needed by Science Pipelines developers could remove LSST's need for this executor entirely, though that would need to be accompanied by hardware configured to use HTCondor jobs instead of / in addition to Slurm jobs during the transition away from Gen2 (that may already exist; I don't know).  It is likely that HSC and PFS would continue to want this, however, and it might be that [~price] would want to be the person to work on this for educational purposes."
Answer: 435205.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: "We should be calling {{config.validate()}} on all tasks when running Pipelines.  Turning that on should be easy, but there's a pretty good chance that will reveal something broken in our configurations that needs to be fixed.    If done after full-Pipeline contract-based validation is available (probably DM21421), that should be included as well."
Answer: 62178.0

User story: "It'd be very nice if at least most {{pipetask}} options could be passed before or after the subcommand, instead of requiring users to remember which options go where.    It's entirely possible this is a fundamental limitation of Python's argparse, but if that's the case I think we should strongly consider some way to mitigate the problem, perhaps even by duplicating all current top-level options for each subcommand so options always go after the subcommand."
Answer: 23977.0

User story: "The one I'm particularly aware of is {{-t}}, which is used in one context for TIMEOUT and another for Tasks.  We should do a sweep for others.    This may be best handled as part of an overall re-think of the command-line interface that maximizes consistency with other tools (DM-15257), but we should make sure to get it done one way or another."
Answer: 23977.0

User story: "DM-21801 and DM-21802 added Gaussian fit and HST-COSMOS imaging options to MultiProFitTask. This ticket is to investigate whether one can identify point sources using COSMOS data and use that information to improve point source classification and/or fitting, especially with MultiProFit."
Answer: 63684.0

User story: "Create a {{PipelineTask}} whose {{runQuantum}} method includes all of the logic in {{ApPipeTask.runAssociation}}.    This should probably be done after DM-21877, so it can use the same approach to signal completion of APDB writes to downstream PipelineTasks.     It's not clear what to do about ownership of {{ApPipeTask.ppdb}}. It must belong to the new task in Gen 3, but doing so will break config overrides in Gen 2 (and the DB location is _always_ overridden)."
Answer: 84117.0

User story: "The {{lsst.verify.MetricTask}} system was designed to be as forward-compatible with PipelineTask as possible, so it should be straightforward to convert it, its subclasses, and any related tasks that are still needed in Gen3.    This is an umbrella ticket for all of that work; I don't know exactly what that would entail, but would like to have any relevant tickets linked here somehow.  I've taken a wild guess at SPs, but would love to have that updated by someone who actually has a decent basis for estimation."
Answer: 78195.0

User story: The version check is added in runIsr.py in the new LSST stack version. Since the binary file of "tests/testData/bsc.db3" will change when running the comcamCloseLoop.py in lsst-ts/ts_phosim, the continuous run of runIsr.py will fail in the same rerun/run1 directory.
Answer: 1794.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 size of PSF measured on the coadds was significantly different from those measured on single visits and warp (see the plot from [~<USER> attached ). This ticket is to process the HSC data and re-make similar plots from the latest repo."
Answer: 313874.0

User story: "Since auth was turned on for stable, the query monkey has been broken.  I'm going to do my best impression of a Star Trek Engineer and reroute it so that it's behind the auth proxy, since there's no way to have long lasting service tokens."
Answer: 13.0

User story: "This summarizes the discussion about astrometry and psfs with several people at UPenn on October 21, 2019. In particular, we discussed fitting atmospheric effects in the astrometric residuals."
Answer: 34543.0

User story: "The culler isn't reaping notebooks anymore.  While a log in cycle will refresh the token on how you get to the notebook, there is currently no way to refresh the token inside of a notebook (which is used to contact TAP).  This means that a lot of people may have expired tokens, and come to me regularly to say that things don't work.  While I'm trying to add in more checks to other places, like a token info notebook and am going to move that logic so that it can be called from the TAP notebook, we should be reaping these notebooks."
Answer: 9904.0

User story: Discussing the Gen 3 migration of {{lsst.ap.pipe.ApPipeTask}} and {{lsst.verify.tasks.PpdbMetricTask}} on [#dm-science-pipelines|https://lsstc.slack.com/archives/C2JPMCF5X/p1571778136107700], [~<USER> and I concluded that the cleanest trigger for running a {{PpdbMetricTask}} would be to provide a dataset that indicates that the database contains all information for a particular data ID. I believe this can also simplify the problem of providing Butler-like input to {{PpdbMetricTask}}.    Prototype this sytem in a Gen 2 pipeline by doing the following:   * Create a new dataset type ({{ppdbConfig}}?), with visit+ccd granularity (matching the units of work of {{ApPipeTask}}).   * Make {{ApPipeTask}} dump its PPDB config at the end of DB-related processing for a particular data ID. Note that while the DB config is fixed, we still should have a dataset for each data ID so that Gen 3 code could know which units of processing are "DB complete".   * Create a new Task for creating a PPDB from a {{ppdbConfig}}, then configure {{PpdbMetricTask}} to use it in {{ap_verify}} runs.    These steps should test all aspects of the system except for tracking dependencies between pipeline and metric tasks, which is a Gen 3-only feature.
Answer: 43258.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 Nublado is scanning all the tags as a part of the recommended thing, if you try to navigate to the spawner page, you'll be an unhappy camper.    Nublado will not show the spawner page, it will instead try to start a container that isn't an LSST container, it's the single-user container from jupyterhub.  And of course, this doesn't work and doesn't spawn properly.  Then you are in a hung state requiring database surgery, or at least a restart of the hub.    Since this period of vulnerability can last for more than a minute or two while it is scanning, this has bit me a number of times when deploying on GKE.  This was also the root cause of a number of strange labs that we weren't sure how they were spawned on NCSA, since people would navigate to the spawner page after a hub restart."
Answer: 1289.0

User story: "Make it possible to persist and unpersist {{lsst.verify.Measurement}} objects via the Gen3 Butler."
Answer: 50575.0

User story: "Create one or more PipelineTasks that allow us to run any image-differencing functionality we need to continue to support in Gen3.  My understanding is that this means we need all calexp-template differencing functionality, but not necessarily pairwise calexp-calexp differencing (I'm hoping [~<USER> and/or [~<USER> can confirm).    I'm creating this now and assigning it to the AP team for middleware planning purposes, with a wild guess at SPs.  We'll of course have some DRP team members helping out with the work (probably [~<USER> and/or [~<USER>).  People doing the work are welcome to turn this into an umbrella ticket in the future with no SPs or branches of its own, but please link blocker tickets to this one so the middleware team can easily track progress towards deprecating Gen2."
Answer: 273803.0

User story: "Install the docker in PhoSim server and change the image pull position setting. Record the steps to let Bo have the idea to follow on his server."
Answer: 23296.0

User story: "Create a spreadsheet with compute and storage needs for Commissioning, pre-Ops, and LOY1, simpler than LDM-139/141/144, along with accompanying descriptive text."
Answer: 7889.0

User story: "The IngestTask is not readily callable by a routine that wishes to ingest one file after another into the same Butler, with errors reported.  Adapt it for this usage."
Answer: 40778.0

User story: "Participate in the DM Bootcamp remotely "
Answer: 61922.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: "DM-21861 adds basic Gen3 butler support for obs_sdss (sufficient for ingest), but we'll need to expand that to get to the point where we can run single-frame processing via Gen3 on it.  That will include, at least:   * implementing {{writeCuratedCalibrations}} in the instrument class;   * specializing (and modifying, as necessary) the instrument-specific hooks for the gen2to3 tool, at least to the point where we can write scripts like the ones in ci_hsc_gen3/bin.src to make a fully-usable Gen3 repo.    SDSS is quite different from most other obs packages because we rely on SDSS Photo pipeline outputs for several different calibrations rather than our own.  That means this ticket will need to involve cooking up ways to ingest those files into Gen3 repos and writing PipelineTask versions of any SDSS-specific CmdLineTasks we use."
Answer: 260604.0

User story: "obs_lsst now has basic Gen3 butler support (sufficient for ingest), but we'll need to expand that to get to the point where we can run single-frame processing (IsrTask, CharacterizeImageTask, and CalibrateTask) via Gen3 on imsim/phosim and IsrTask on all other instruments (or at least the ones for which this is possible in Gen2).  That will include, at least:   * implementing {{writeCuratedCalibrations}} in the instrument class;   * specializing (and modifying, as necessary) the instrument-specific hooks for the gen2to3 tool, at least to the point where we can write scripts like the ones in ci_hsc_gen3/bin.src to make a fully-usable Gen3 repo.     "
Answer: 342668.0

User story: "obs_decam now has basic Gen3 butler support (sufficient for ingest), but we'll need to expand that to get to the point where we can run single-frame processing (IsrTask, CharacterizeImageTask, and CalibrateTask) via Gen3 on it.  That will include, at least:   * implementing {{writeCuratedCalibrations}} in the instrument class;   * specializing (and modifying, as necessary) the instrument-specific hooks for the gen2to3 tool, at least to the point where we can write scripts like the ones in ci_hsc_gen3/bin.src to make a fully-usable Gen3 repo.    I'm assigning this to [~<USER> and the AP team for now, in the hopes it might be possible for him to finish the work he started with the initial DECam conversion.    A useful concrete end-point for this task would be a CI package that creates a Gen3 repo containing the HiTS (2015) raws, master calibrations, reference catalogs and runs the aforementioned tasks as a Pipeline."
Answer: 233388.0

User story: "Add an Instrument class and PipelineTask config overrides sufficient to ingest SDSS data into a Gen3 butler repository.    This may uncover issues in astro_metadata_translator for SDSS, because SDSS has unusual (due to drift-scan observing) identifiers that may be hard to map well to exposures and visits, and this will be the first time we've really exercised them."
Answer: 260630.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: "Add an Instrument class and PipelineTask config overrides sufficient to ingest CFHT data into a Gen3 butler repository."
Answer: 468613.0

User story: "My understanding is that some of the integer Registry ID fields populated by astro_metadata_translator for some kinds of LSST data are not guaranteed to be globally unique - I think that's about date + sequence number IDs not being a unique exposure_id unless the control system is specified as well, but I'm hoping [~<USER> can correct me if I'm wrong about that (while guessing what I'm actually thinking of).    We need to fix this somehow - the easiest solution seems to be adding a few bits to represent whatever variable(s) are missing.  I'm pretty sure we don't have any requirement that these IDs be ordered with time, so hopefully that will make this pretty easy (it may be _convenient_ for users to be able to express ranges of visits in time as ranges of integers, but I bet we'll mostly get that anyway, as in operations we're not going to be switching control systems much).    This ticket does not need to include generating integer IDs for visits; I'll raise that on a new ticket (and I don't think it will need to involve astro_metadata_translator)."
Answer: 75116.0

User story: "This move has long been planned.  Time to do it."
Answer: 24984.0

User story: Both PostgreSQL and Oracle put limits on the lengths of database names that we've run into at one point or another, and while so far that's been limited to the names of things whose names don't matter much (e.g. foreign key constraints), future functionality that depends on dynamic table creation will make it more likely for this to extend to more visible names.    We should adopt a scheme for truncating database names while retaining uniqueness (e.g. "replace any characters after the Nth with a length-M hash of them"), and apply it to all symbols.  This should not affect the names used in any Python code.
Answer: 122731.0

User story: "Currently acks are being published after work is done. That creates confusion to the ATArchiver that Forwarder is down. So, acks should be published before work."
Answer: 3290.0

User story: "Spatial joins in the Gen3 Registry are handled via tables that fully expand the skypix IDs for each region.  Because any skypix system we'd consider uses a space filling curve, those will frequently involve many consecutive IDs, and we could instead switching to an approach where the join tables stored ranges via begin and end skypix IDs.  joins would then involve many fewer rows, but with much more complex comparison expressions.    This should be implemented in a way that makes it configurable per-repo.  We should also consult database experts to see if there are special index types that should be used for interval comparisons."
Answer: 243556.0