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

Write technote on how to rename a package

    XMLWordPrintable

    Details

      Description

      On recommendation from Tim Jenness, I'm writing a short technote describing how to rename an LSST package, based on my experience from DM-7915.

        Attachments

          Issue Links

            Activity

            Hide
            Parejkoj John Parejko added a comment -

            Tim and Nate: could you please review the document? The latest version is available at this link:

            https://dmtn-027.lsst.io/v/DM-7957/index.html

            Nate: I stole what you'd written for Perry Gee in the other ticket and fleshed it out a bit. Please let me know if I said anything incorrect in the "Merging in work" section.

            Show
            Parejkoj John Parejko added a comment - Tim and Nate: could you please review the document? The latest version is available at this link: https://dmtn-027.lsst.io/v/DM-7957/index.html Nate: I stole what you'd written for Perry Gee in the other ticket and fleshed it out a bit. Please let me know if I said anything incorrect in the "Merging in work" section.
            Hide
            tjenness Tim Jenness added a comment -

            Looks great. This is really helpful. Minor comments:

            • Add link to RFC process in developer guide when mentioning RFC.
            • In the updating lsstsw repos.yaml section link to the dev guide where we talk about that.
            • In "Update dependent packages" they need to update the ups/xxx.cfg files as well.
            • Merging in work section: Missed a pipe_best code markup in bullet 3. Also the rst reference is unresolved later in #3.

            I'll let Nate Pease [X] mark the ticket reviewed when he is done.

            Show
            tjenness Tim Jenness added a comment - Looks great. This is really helpful. Minor comments: Add link to RFC process in developer guide when mentioning RFC. In the updating lsstsw repos.yaml section link to the dev guide where we talk about that. In "Update dependent packages" they need to update the ups/xxx.cfg files as well. Merging in work section: Missed a pipe_best code markup in bullet 3. Also the rst reference is unresolved later in #3. I'll let Nate Pease [X] mark the ticket reviewed when he is done.
            Hide
            Parejkoj John Parejko added a comment -

            I've updated based on Tim's comment above, plus a significant rewrite of the "merging work" section.

            Show
            Parejkoj John Parejko added a comment - I've updated based on Tim's comment above, plus a significant rewrite of the "merging work" section.
            Hide
            npease Nate Pease [X] (Inactive) added a comment - - edited

            Overall the doc looks very good. I think there is one process point to address, and if people agree with it then I think it should make its way into the document:

            Before the fork to pipe_best happens, developers with work in progress should have a chance to push any local changes in their branches to meas_worst, so that their branches will also exist in pipe_best after the fork.
            (one of the reasons it ended up being easy for me to integrate my changes was that I had pushed all my branches to daf_butlerUtils before leaving for vacation, before the fork to obs_base happened).
            The person who will do the rename should find developers with work in progress (I put details about how to do that below) and work out a time to do the change, giving them a chance to push all their latest work

            This is a subtle difference from our normal workflow where I've heard it put: "first to master wins", which is ok by me given the usual caveats about publishing API changes and doing RFC's and whatnot. The difference in this case is that other devs should be allowed the chance to send all the latest work in their branches along with the fork.

            I think there's 2 ways I know of to figure out who may have work in progress:

            The first is to look for active branches on github:
            1. go to the package home page on github
            2. click on the 'code' tab (if needed, I think it's the default tab)
            3. click on the sub tab that shows the number of branches e.g. it will say something like "101 branches"
            4. click on the 'active' tab to see active branches and who owns them.

            The other way is to search for the component in lira:
            search for issues with status "in progress" and where the component matches the package name

            If we adopt this process, then the section "Merging in work that had started on the old package" changes to
            1. Before meas_worst is forked, push your meas_worst changes to github on your branch.
            2. After the rename is complete, clone pipe_best: git clone https://github.com/lsst-dm/pipe_best (it would also work to instead do 'rebuild pipe_best', which will clone pipe_best into the 'lsstsw/build' directory)
            3. Checkout your branch; it should exist in pipe_best. If it does not, or if it is not up-to-date with your latest changes in meas_worst, you may have to follow the `syncing a fork`_ instructions.
            4. Rebase to pipe_best master: git rebase master
            5. Fix any conflicts. There may be a few, if you modified lines around statements that were changed during the rename.
            6. Commit and push your branch to pipe_best, and continue your work.

            Show
            npease Nate Pease [X] (Inactive) added a comment - - edited Overall the doc looks very good. I think there is one process point to address, and if people agree with it then I think it should make its way into the document: Before the fork to pipe_best happens, developers with work in progress should have a chance to push any local changes in their branches to meas_worst, so that their branches will also exist in pipe_best after the fork. (one of the reasons it ended up being easy for me to integrate my changes was that I had pushed all my branches to daf_butlerUtils before leaving for vacation, before the fork to obs_base happened). The person who will do the rename should find developers with work in progress (I put details about how to do that below) and work out a time to do the change, giving them a chance to push all their latest work This is a subtle difference from our normal workflow where I've heard it put: "first to master wins", which is ok by me given the usual caveats about publishing API changes and doing RFC's and whatnot. The difference in this case is that other devs should be allowed the chance to send all the latest work in their branches along with the fork. I think there's 2 ways I know of to figure out who may have work in progress: The first is to look for active branches on github: 1. go to the package home page on github 2. click on the 'code' tab (if needed, I think it's the default tab) 3. click on the sub tab that shows the number of branches e.g. it will say something like "101 branches" 4. click on the 'active' tab to see active branches and who owns them. The other way is to search for the component in lira: search for issues with status "in progress" and where the component matches the package name If we adopt this process, then the section "Merging in work that had started on the old package" changes to 1. Before meas_worst is forked, push your meas_worst changes to github on your branch. 2. After the rename is complete, clone pipe_best: git clone https://github.com/lsst-dm/pipe_best (it would also work to instead do 'rebuild pipe_best', which will clone pipe_best into the 'lsstsw/build' directory) 3. Checkout your branch; it should exist in pipe_best. If it does not, or if it is not up-to-date with your latest changes in meas_worst, you may have to follow the `syncing a fork`_ instructions. 4. Rebase to pipe_best master: git rebase master 5. Fix any conflicts. There may be a few, if you modified lines around statements that were changed during the rename. 6. Commit and push your branch to pipe_best, and continue your work.
            Hide
            tjenness Tim Jenness added a comment -

            Asking people to push work in progress is good and should be explicit, but you can't guarantee you'll catch everyone (they might be on vacation) so you still have to include instructions on how to recover if the fork happened and the branch was out of date on github beforehand.

            Show
            tjenness Tim Jenness added a comment - Asking people to push work in progress is good and should be explicit, but you can't guarantee you'll catch everyone (they might be on vacation) so you still have to include instructions on how to recover if the fork happened and the branch was out of date on github beforehand.
            Hide
            npease Nate Pease [X] (Inactive) added a comment -

            I guess I should leave this as 'in review' while we decide this point.

            Show
            npease Nate Pease [X] (Inactive) added a comment - I guess I should leave this as 'in review' while we decide this point.
            Hide
            npease Nate Pease [X] (Inactive) added a comment -

            you still have to include instructions on how to recover if the fork happened and the branch was out of date on github beforehand.

            I was lucky enough to not have to deal with that. Perry Gee, did you use git to recover your not-pushed branch? Can you write something up about that for the tech note?

            Show
            npease Nate Pease [X] (Inactive) added a comment - you still have to include instructions on how to recover if the fork happened and the branch was out of date on github beforehand. I was lucky enough to not have to deal with that. Perry Gee , did you use git to recover your not-pushed branch? Can you write something up about that for the tech note?
            Hide
            Parejkoj John Parejko added a comment -

            I'll add something about trying to get the attention of other developers with work in branches, but I'm confused about your comment here:

            you still have to include instructions on how to recover if the fork happened and the branch was out of date on github beforehand.

            I was lucky enough to not have to deal with that. Perry Gee, did you use git to recover your not-pushed branch? Can you write something up about that for the tech note?

            There's a whole section of the document devoted to this topic, with step-by-step instructions.

            Show
            Parejkoj John Parejko added a comment - I'll add something about trying to get the attention of other developers with work in branches, but I'm confused about your comment here: you still have to include instructions on how to recover if the fork happened and the branch was out of date on github beforehand. I was lucky enough to not have to deal with that. Perry Gee, did you use git to recover your not-pushed branch? Can you write something up about that for the tech note? There's a whole section of the document devoted to this topic, with step-by-step instructions.
            Hide
            npease Nate Pease [X] (Inactive) added a comment -

            There's a whole section of the document devoted to this topic, with step-by-step instructions.

            Oh, of course there it is. (I clearly need a second cup of coffee). So: sorry, and never mind about that part.

            Show
            npease Nate Pease [X] (Inactive) added a comment - There's a whole section of the document devoted to this topic, with step-by-step instructions. Oh, of course there it is. (I clearly need a second cup of coffee). So: sorry, and never mind about that part.
            Hide
            Parejkoj John Parejko added a comment -

            I've added a section about developer coordination. Please take a look and tell me what you think. I also tweaked a bit of the text to clarify whether something was to be done on github or on the local clone.

            https://dmtn-027.lsst.io/v/DM-7957/index.html#coordinating-with-other-developers
            https://github.com/lsst-dm/dmtn-027/pull/2/commits/0bbdd4838944c82c2a64e3998f198fe85f62dfd0

            Show
            Parejkoj John Parejko added a comment - I've added a section about developer coordination. Please take a look and tell me what you think. I also tweaked a bit of the text to clarify whether something was to be done on github or on the local clone. https://dmtn-027.lsst.io/v/DM-7957/index.html#coordinating-with-other-developers https://github.com/lsst-dm/dmtn-027/pull/2/commits/0bbdd4838944c82c2a64e3998f198fe85f62dfd0
            Hide
            npease Nate Pease [X] (Inactive) added a comment -

            looks great. thanks for writing that up. setting to 'reviewed'

            Show
            npease Nate Pease [X] (Inactive) added a comment - looks great. thanks for writing that up. setting to 'reviewed'
            Hide
            Parejkoj John Parejko added a comment -

            Thank you for the review comments. It's a stronger document for it. This is now live!

            https://dmtn-027.lsst.io/

            Show
            Parejkoj John Parejko added a comment - Thank you for the review comments. It's a stronger document for it. This is now live! https://dmtn-027.lsst.io/

              People

              Assignee:
              Parejkoj John Parejko
              Reporter:
              Parejkoj John Parejko
              Reviewers:
              Nate Pease [X] (Inactive), Tim Jenness
              Watchers:
              John Parejko, Kian-Tat Lim, Nate Pease [X] (Inactive), Perry Gee, Simon Krughoff, Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.