Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-561

Adopt new version of LDM-294 as baseline -Documentalist, DMCCB, Release Management, Product Tree

    XMLWordPrintable

Details

    • RFC
    • Status: Implemented
    • Resolution: Done
    • DM, TCT
    • None

    Description

      In respect to the baselined version (June 2018) following updates have been included into master:

      • Improved makeProductTree.py
      • In section 7:
        • DM System Engineering Team
        • DM configuration Control Board
      • In section 3:
        • Release Management
        • Figure 5: DM Organization

       

      The pdf of the new version is available here.

      The updated top level product tree is available here.

      Attachments

        Issue Links

          Activity

            The title of the RFC was wrong (referring to LDM-503). Now it is correct.

            gcomoretto Gabriele Comoretto [X] (Inactive) added a comment - The title of the RFC was wrong (referring to LDM-503). Now it is correct.

            For the convenience of anybody else looking at this, I'll point out that you can see the full set of changes relative to the currently baselined version at https://github.com/lsst/LDM-294/compare/docushare-v9...master

            swinbank John Swinbank added a comment - For the convenience of anybody else looking at this, I'll point out that you can see the full set of changes relative to the currently baselined version at https://github.com/lsst/LDM-294/compare/docushare-v9...master
            swinbank John Swinbank added a comment - - edited

            Per my comments on DM-16947, I still don't understand the apparent change to the remit of the DM-CCB here — we go from “scope restricted to the DM subsystem” to “focused on the DM subsystem”. This seems to imply the DM-CCB might sometimes do things that aren't relevant to DM... is that the intention?

            Again per DM-16947, most T/CAMs don't have deputies, so suggesting that they delegate to them seems unfortunate.

            And again per DM-16947, as of today LDM-564 doesn't describe a meaningful release plan. I think it would be appropriate (and in keeping with its title!) to convert LDM-564 into a release plan, but that work hasn't happened. Until it does, I don't think we should baseline a version of LDM-294 which asserts that LDM-564 describes a release plan.

            (Why do I say LDM-564 isn't a release plan? Because e.g. the following don't correspond to releases:

            • Science Platform with WISE data in PDAC
            • HSC reprocessing
            • Alert generation validation
            • AuxTel DAQ integration functionality test
            • Aux Tel DAQ interface Integration Verification and Spectrograph Operations Rehearsal
            • Alert distribution validation

            It might be ok to approve this document as is, if a ticket were filed and cited in the document to describe the work of converting LDM-564 into a release plan.)

            swinbank John Swinbank added a comment - - edited Per my comments on DM-16947 , I still don't understand the apparent change to the remit of the DM-CCB here — we go from “scope restricted to the DM subsystem” to “focused on the DM subsystem”. This seems to imply the DM-CCB might sometimes do things that aren't relevant to DM... is that the intention? Again per DM-16947 , most T/CAMs don't have deputies, so suggesting that they delegate to them seems unfortunate. And again per DM-16947 , as of today LDM-564 doesn't describe a meaningful release plan. I think it would be appropriate (and in keeping with its title!) to convert LDM-564 into a release plan, but that work hasn't happened. Until it does, I don't think we should baseline a version of LDM-294 which asserts that LDM-564 describes a release plan. (Why do I say LDM-564 isn't a release plan? Because e.g. the following don't correspond to releases: Science Platform with WISE data in PDAC HSC reprocessing Alert generation validation AuxTel DAQ integration functionality test Aux Tel DAQ interface Integration Verification and Spectrograph Operations Rehearsal Alert distribution validation It might be ok to approve this document as is, if a ticket were filed and cited in the document to describe the work of converting LDM-564 into a release plan.)

            It wasn't clear to me from the wording of this RFC, but according to the DMLT of 2019-01-14 “Improved makeProductTree.py” indicates there are substantive changes to the contents of the product tree, not just the mechanisms used to generate it. We should also review those in the context of this document.

            swinbank John Swinbank added a comment - It wasn't clear to me from the wording of this RFC, but according to the DMLT of 2019-01-14 “Improved makeProductTree.py” indicates there are substantive changes to the contents of the product tree, not just the mechanisms used to generate it. We should also review those in the context of this document.

            swinbank, if a T/CAM has not deputy, and he/she will not be able to participate, the CCB will go on without his/her contribution.

             

            Regarding making LDM-564 consistent with LDM-294, there is already an issue opened, DM-17001. I will mention it in LDM-294.

            gcomoretto Gabriele Comoretto [X] (Inactive) added a comment - swinbank , if a T/CAM has not deputy, and he/she will not be able to participate, the CCB will go on without his/her contribution.   Regarding making LDM-564 consistent with LDM-294, there is already an issue opened, DM-17001 . I will mention it in LDM-294.

            Comments from DMCCB1 has been added to the RFC-561 ticket branch.

            gcomoretto Gabriele Comoretto [X] (Inactive) added a comment - Comments from DMCCB1 has been added to the RFC-561 ticket branch.

            The outstanding discrepancy between the product tree in LDM-294 and LDM-148 is now documented in DM-17448.

            I suggest to consider this RFC adopted.

            gcomoretto Gabriele Comoretto [X] (Inactive) added a comment - The outstanding discrepancy between the product tree in LDM-294 and LDM-148 is now documented in DM-17448 . I suggest to consider this RFC adopted.

            I discussed this with gcomoretto today. I understand that the intention is that this RFC provides only an incidental update to the product tree. DM-17439 will provide the fully updated product tree which is consistent with other DM documentation (or, where that's not possible, the documents delivered by DM-17439 will point out discrepancies and explain why they exist).

            On that basis, I have no objection to adopting this RFC.

            swinbank John Swinbank added a comment - I discussed this with gcomoretto today. I understand that the intention is that this RFC provides only an incidental update to the product tree. DM-17439 will provide the fully updated product tree which is consistent with other DM documentation (or, where that's not possible, the documents delivered by DM-17439 will point out discrepancies and explain why they exist). On that basis, I have no objection to adopting this RFC.
            ebellm Eric Bellm added a comment -

            The proposed changes give the CCB the responsibility to "Review and approve all RFCs prior to 'Adoption'." Appendix C of this document and https://developer.lsst.io/communications/rfc.html should be updated accordingly, and this change communicated to all of DM via a community post or similar.

            ebellm Eric Bellm added a comment - The proposed changes give the CCB the responsibility to "Review and approve all RFCs prior to 'Adoption'." Appendix C of this document and https://developer.lsst.io/communications/rfc.html should be updated accordingly, and this change communicated to all of DM via a community post or similar.
            tjenness Tim Jenness added a comment -

            I don't think that's what we mean. I thought that DM-CCB are saying that they will look at every RFC and see whether the DM-CCB need to be involved. If so the RFC will be flagged. There is no requirement that every RFC be approved by the DM-CCB (that won't stop the CCB saying "looks okay to us").

            tjenness Tim Jenness added a comment - I don't think that's what we mean. I thought that DM-CCB are saying that they will look at every RFC and see whether the DM-CCB need to be involved. If so the RFC will be flagged. There is no requirement that every RFC be approved by the DM-CCB (that won't stop the CCB saying "looks okay to us").
            ebellm Eric Bellm added a comment -

            I'd suggest rephrasing that point, then, given my naive reading of "and approve." Maybe "Review all RFCs prior to 'Adoption' and escalate those within DM-CCB scope" ? or similar?

            ebellm Eric Bellm added a comment - I'd suggest rephrasing that point, then, given my naive reading of "and approve." Maybe "Review all RFCs prior to 'Adoption' and escalate those within DM-CCB scope" ? or similar?
            tjenness Tim Jenness added a comment -

            That would agree with my reading of the situation but I'd like womullan to comment before gcomoretto makes the change.

            tjenness Tim Jenness added a comment - That would agree with my reading of the situation but I'd like womullan to comment before gcomoretto makes the change.
            tjenness Tim Jenness added a comment -

            ebellm, I have re-read the text in the document (thanks gcomoretto) and it says:

            Review all RFCs and approves flagged RFCs prior to ’Adoption’.

            which is not quite what you mention above. This is consistent with what I thought we were saying.

            tjenness Tim Jenness added a comment - ebellm , I have re-read the text in the document (thanks gcomoretto ) and it says: Review all RFCs and approves flagged RFCs prior to ’Adoption’. which is not quite what you mention above. This is consistent with what I thought we were saying.
            ebellm Eric Bellm added a comment -

            tjenness I apologize, I was looking at the docushare-v9 diff and didn't realize it had changed in the most recent version--I agree that the current wording is fine.

            ebellm Eric Bellm added a comment - tjenness I apologize, I was looking at the docushare-v9 diff and didn't realize it had changed in the most recent version--I agree that the current wording is fine.

            Lets get the new version out and close this.

            womullan Wil O'Mullane added a comment - Lets get the new version out and close this.

            People

              gcomoretto Gabriele Comoretto [X] (Inactive)
              gcomoretto Gabriele Comoretto [X] (Inactive)
              Eric Bellm, Gabriele Comoretto [X] (Inactive), John Swinbank, Kian-Tat Lim, Leanne Guy, Tim Jenness, Wil O'Mullane
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                Planned End:

                Jenkins

                  No builds found.