As Kamil already wrote, the number of notifications, issues and merge requests that we follow is enormous and sometimes something may be missed. I'm doing my best to have eye on everything but this is not always possible.
From my side I can only say that I'm very sorry that your work and work of all people engaged in this merge request was noticed so late. We're working on improving responsiveness in GitLab Runner project so hopefully we will avoid such delays in the future.
Tomasz, developer at GitLab, GitLab Runner project maintainer
Thanks for writing that comment and making us aware of that case. I'm very sorry that it did that long to get reviewed and merged. The number of issues and merge requests that pass our hands is just crazy and sometimes it happens that some of them are oversight and not properly scheduled. Having people to be persistent, like you, makes them finally to be merged and be part of the product. Thank you for doing that! From our side, we will try our best to make this process to be more efficient.
Kamil, CI/CD Lead at GitLab
One point may not have been clear-- this isn't just a matter of a single bugfix being available to the userbase sooner rather than later. Rather, it is that multiple iterations through a development cycle were missed. From my rough recollection:
1. There was a problem setting up an OSX guest to work with virtualbox runner on OSX with passwords. We worked around this using pubkey-based auth between guest and host.
2. There was also a timeout issue mentioned on the tracker for which Sam found the relevant code and suggested (but did not create) a fix.
3. Sam seemed to think a snapshot-reuse approach was too complex and likely to hang or fail. I didn't agree and was trying to explore ways in which they could run reliably as it cut CI time in half for my use case.
4. For uploading artifacts, the OSX guest's gitlab-runner binary had the wrong name requiring the user to manually create a symlink with the correct name. (I think this is fixed in 9.0, but not sure since I still have the symlink there and it's still working.)
At the time my CI builds (and probably Sam's) weren't working at all, so we both ate the cost of learning how the CI build system worked in order to debug it. If there had been feedback saying that his MR was the right (or wrong) approach I would have been happy to apply my knowledge gained at the time to the related problems mentioned above in order to debug and eventually fix them.
But now that knowledge is gone. The cost for me to regain it outweighs the benefits of small improvements to what is atm a working if imperfect system.
Edit: formatting
Can GitLab have a hands-on demo at the upcoming DataOps Summit in Boston? https://www.dataopssummit.com/
On the other hand, I found it absurdly difficult to get feedback or action from Gitlab on an MR. There was an MR that fixed a critical problem in the virtualbox runner, and it sat there for about 5 months with no response to either the original submitter or my emails to gitlab/gitlab ci maintainers. About a month ago I finally decided to abuse your customer support addy to ask if somebody could force the maintainer to respond before the code rots. By that time the original submitter (who in comparison turned out to be easy to contact and collaborate with) was long gone. And another user had already announced a separate script they developed and maintained to work around the lack of merging this fix.
I'm glad it finally got merged, but it was only after deciding to use my free time and treat the process as a kind of game to be beaten. But that's a one-off game I won't play again. Plus I doubt the original submitter, a Go developer, will be making another merge request.
Anyhow, I made a list on the relevant issue tracker of the work it took to get the maintainer to eventually click the "merge" button: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_r...