Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-1056

DS9 use wrt Releases and/or Example Release Use

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: SAT
    • Labels:
    • Team:
      Architecture

      Description

      DS9 is being used in examples illustrating the use of DM Releases.

      DS9 was formerly considered a developer-only 3rd party tool and not bundled in a release. Nor was it included in the DM Copyright statement listing the 3rd Party Tools required.

      Dick raises the question whether it needs to be promoted in status or just mentioned as a potentially useful user-supplied tool.

        Attachments

          Issue Links

            Activity

            Hide
            mjuric Mario Juric added a comment -

            Kian-Tat Lim, Robyn Allsman [X]: I understand the theoretical arguments behind it, but I fear that enacting this recommendation in full would cause more harm than good in practice, due to the following:

            1. If I understand correctly, afw.display is the only option we offer at the moment to visualize our various internal objects while debugging. Administratively prohibiting making it possible to easily obtain the (optional) package required for afw.display to work increases the barrier to entry and developer frustration.
            2. I'd actually argue that it would be beneficial to us if the developers begun depending on afw.display more rather than less. That would further expose any design issues in the current prototype, and allow us to make a better abstract design in the future.
            3. Though I talk about afw.display here, I'm actually worried about how this will generalize to other exploratory implementations of various features. Or would a potential deployment of (say) gcc 4.6 be disallowed by this rule?

            Therefore, I'd propose a compromise: how about if we enact this recommendation, but make it contingent on setting up a second distribution server (I'd propose http://sw.lsstcorp.org/contrib) where "unsupported" packages could be added easily with little (no) discussion?

            Show
            mjuric Mario Juric added a comment - Kian-Tat Lim , Robyn Allsman [X] : I understand the theoretical arguments behind it, but I fear that enacting this recommendation in full would cause more harm than good in practice, due to the following: If I understand correctly, afw.display is the only option we offer at the moment to visualize our various internal objects while debugging. Administratively prohibiting making it possible to easily obtain the (optional) package required for afw.display to work increases the barrier to entry and developer frustration. I'd actually argue that it would be beneficial to us if the developers begun depending on afw.display more rather than less. That would further expose any design issues in the current prototype, and allow us to make a better abstract design in the future. Though I talk about afw.display here, I'm actually worried about how this will generalize to other exploratory implementations of various features. Or would a potential deployment of (say) gcc 4.6 be disallowed by this rule? Therefore, I'd propose a compromise: how about if we enact this recommendation, but make it contingent on setting up a second distribution server (I'd propose http://sw.lsstcorp.org/contrib ) where "unsupported" packages could be added easily with little (no) discussion?
            Hide
            robyn Robyn Allsman [X] (Inactive) added a comment -

            Your proposal satisfies what I view as the TCT approval requirement of packages in the official Release stack. SQuaRE would need to build a stack excluding all optional packages and use that for its AcceptanceTesting (or as a phase of that level of testing). If there are a suite of equivalent package options, the testing stack would include the TCT-approved preferred package.

            Of course, the daily CI would integrate the optional packages as desired for purposes of development and test.

            So your compromise of a second distribution server for the optionals would make the distinction more obvious to all.

            Show
            robyn Robyn Allsman [X] (Inactive) added a comment - Your proposal satisfies what I view as the TCT approval requirement of packages in the official Release stack. SQuaRE would need to build a stack excluding all optional packages and use that for its AcceptanceTesting (or as a phase of that level of testing). If there are a suite of equivalent package options, the testing stack would include the TCT-approved preferred package. Of course, the daily CI would integrate the optional packages as desired for purposes of development and test. So your compromise of a second distribution server for the optionals would make the distinction more obvious to all.
            Hide
            ktl Kian-Tat Lim added a comment -

            After further discussion, the SAT on 2014-10-14 changed its recommended policy statement to be: Distribution of optional packages from the DM software distribution server is allowed (but not mandated) as long as someone in DM is using the package and will own and maintain it. The exact mechanism for claiming ownership is to be determined.

            Show
            ktl Kian-Tat Lim added a comment - After further discussion, the SAT on 2014-10-14 changed its recommended policy statement to be: Distribution of optional packages from the DM software distribution server is allowed (but not mandated) as long as someone in DM is using the package and will own and maintain it. The exact mechanism for claiming ownership is to be determined.
            Hide
            robyn Robyn Allsman [X] (Inactive) added a comment - - edited

            Kian-Tat Lim Frossie Economou I'm getting back to this a little late... When you are discussing the TCT/SAT relationship at DMLT Nov2014, please review whether this Policy even needs TCT approval. The TCT is supposed to sanction every change to Official DM Software Releases (i.e., the 6 or 12 month Releases). This Issue discusses the addition of 'new' 3rd party software on which the Release does not depend – i.e. if it wasn't there, the Release would still build and could be used in Production if it passed all QA tests. Until that 3rd party software becomes a required artifact for a Release's build, it doesn't need TCT approval. It's up to the SAT to determine if a 3rd party software is acceptable for exploratory mode - which I would class as any optional dependency.

            So wrt the TCT current mandate, this is not relevant. Once the TCT mandate is revised, you should revisit this issue keeping in mind the new mandate.

            Regardless of outcome, this Policy statement should be added to https://confluence.lsstcorp.org/display/DM/DM+Third+Party+Software so the SQuaRE team has a summary of all TCT approved software allowed in an Official DM Software Release and all SAT approved optional/experimental software. (And it just was added there.)

            Show
            robyn Robyn Allsman [X] (Inactive) added a comment - - edited Kian-Tat Lim Frossie Economou I'm getting back to this a little late... When you are discussing the TCT/SAT relationship at DMLT Nov2014, please review whether this Policy even needs TCT approval. The TCT is supposed to sanction every change to Official DM Software Releases (i.e., the 6 or 12 month Releases). This Issue discusses the addition of 'new' 3rd party software on which the Release does not depend – i.e. if it wasn't there, the Release would still build and could be used in Production if it passed all QA tests. Until that 3rd party software becomes a required artifact for a Release's build, it doesn't need TCT approval. It's up to the SAT to determine if a 3rd party software is acceptable for exploratory mode - which I would class as any optional dependency. So wrt the TCT current mandate, this is not relevant. Once the TCT mandate is revised, you should revisit this issue keeping in mind the new mandate. Regardless of outcome, this Policy statement should be added to https://confluence.lsstcorp.org/display/DM/DM+Third+Party+Software so the SQuaRE team has a summary of all TCT approved software allowed in an Official DM Software Release and all SAT approved optional/experimental software. (And it just was added there.)
            Hide
            robyn Robyn Allsman [X] (Inactive) added a comment -

            Kian-Tat Lim – isn't this done?

            Show
            robyn Robyn Allsman [X] (Inactive) added a comment - Kian-Tat Lim – isn't this done?

              People

              • Assignee:
                ktl Kian-Tat Lim
                Reporter:
                robyn Robyn Allsman [X] (Inactive)
                Reviewers:
                Jeff Kantor, Mario Juric, Robyn Allsman [X] (Inactive)
                Watchers:
                Jeff Kantor, Kian-Tat Lim, Mario Juric
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel