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

Strip branches from afw

    Details

    • Type: RFC
    • Status: Retired
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None

      Description

      It's a persistent thorn in our side that the Jira-GitHub integration sometimes fails to pick up some branches and/or pull requests (see DM-9697, DM-14876, etc).

      The most common theory (which, I understand, is supported by some evidence, but hasn't been conclusively proved) is that this is caused by an excessive number of branches in our repositories, and particularly in afw. And we certainly have a lot of branches — as of when I last pulled, there are 470 branches in afw; 300 of them haven't been merged; 266 of them predate 2018.

      Of course, those branches contain useful information. Some are work which hasn't been merged but might be useful someday; others are necessary for properly tracking development history. We've made some effort to cull branches in the past, but have been prevented from going too far by the desire not to be destructive.

      I therefore propose a more radical solution. Specifically, we should:

      • Copy the existing afw repository to lsst-dm/afw-archive;
      • Remove all merged branches, and all unmerged branches predating 2018, from lsst/afw.

      In this way, history is not lost (although accessing it will be significantly clunkier), and the total number of branches will be much reduced (to 34, if my count is correct).

      If this doesn't get Jira-Github integration moving smoothly within a relatively short period (say, a couple of days), we can restore from lsst-dm/afw-archive and, with a little cherry-picking, should be back to exactly where we are today.

      This RFC is a genuine request for comments — I am not particularly advocating the proposal above, but genuinely appealing to the developer community to see whether folks value access to historical information or convenient Jira-GitHub integration more highly.

        Attachments

          Issue Links

            Activity

            Hide
            tjenness Tim Jenness added a comment -

            pipe_tasks has 290 branches but is also absent from Jira. Is the threshold around 150 then?

            Show
            tjenness Tim Jenness added a comment - pipe_tasks has 290 branches but is also absent from Jira. Is the threshold around 150 then?
            Hide
            swinbank John Swinbank added a comment -

            My reading of the discussion above is that there's some uncertainty as to whether this proposal will actually do the trick, but that it's worth trying on the basis that we can quickly revert if it doesn't.

            I propose to file an implementation ticket and adopt this RFC on that basis.

            Show
            swinbank John Swinbank added a comment - My reading of the discussion above is that there's some uncertainty as to whether this proposal will actually do the trick, but that it's worth trying on the basis that we can quickly revert if it doesn't. I propose to file an implementation ticket and adopt this RFC on that basis.
            Hide
            ktl Kian-Tat Lim added a comment -

            I suspect that this has some relationship to the threshold (from https://developer.github.com/v3/#pagination):

            Pagination

            Requests that return multiple items will be paginated to 30 items by default. You can specify further pages with the ?page parameter. For some resources, you can also set a custom page size up to 100 with the ?per_page parameter.

            Show
            ktl Kian-Tat Lim added a comment - I suspect that this has some relationship to the threshold (from https://developer.github.com/v3/#pagination ): Pagination Requests that return multiple items will be paginated to 30 items by default. You can specify further pages with the  ?page  parameter. For some resources, you can also set a custom page size up to 100 with the  ?per_page  parameter.
            Hide
            swinbank John Swinbank added a comment -

            I believe that Frossie Economou has done magic such that Jira-GitHub integration is now working ok, and therefore I'm retiring this RFC.

            Show
            swinbank John Swinbank added a comment - I believe that Frossie Economou has done magic such that Jira-GitHub integration is now working ok, and therefore I'm retiring this RFC.
            Hide
            frossie Frossie Economou added a comment -

            Yes I think we are good though performance is always going to be better with fewer branches and really personally I find it confusing to orient myself when there are gazillions of them, so would argue for keeping them down anyway.

            Show
            frossie Frossie Economou added a comment - Yes I think we are good though performance is always going to be better with fewer branches and really personally I find it confusing to orient myself when there are gazillions of them, so would argue for keeping them down anyway.

              People

              • Assignee:
                swinbank John Swinbank
                Reporter:
                swinbank John Swinbank
                Watchers:
                Fritz Mueller, Frossie Economou, John Parejko, John Swinbank, Kian-Tat Lim, Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel