Open philipstarkey opened 5 years ago
Original comment by Philip Starkey (Bitbucket: philipstarkey, GitHub: philipstarkey).
Original comment by Philip Starkey (Bitbucket: philipstarkey, GitHub: philipstarkey).
Regarding the Bitbucket → GitHub issue importer: It looks like there is a fork of the repository made by sphinx-doc that will convert changeset URLs! So we probably don’t have to do this ourselves. Also, a fork of that fork seems to have added support for Bitbucket teams, which we’ll need for the labscript suite (I had no idea it would be different).
So I think if we add any additional features (for instance proper attribution to users by collecting access tokens from them), we should fork this repository.
Original comment by Philip Starkey (Bitbucket: philipstarkey, GitHub: philipstarkey).
Gah, forget that. I missed one link in the chain of forks and didn’t realise how behind it was. That repository doesn’t work!
We will have to look at the changes in the sphinx-doc fork and the one linked above, and merge them into a fork of the master repository I think. At least we don’t have to figure out the logic for mapping URLs…it’s just a matter of bashing the bits of code together.
Original comment by fretchen (Bitbucket: fretchen).
I could set up the labscriptsuite organization if this does not get into anyones way. Then I would also make the necessary people admins ?
Original comment by Philip Starkey (Bitbucket: philipstarkey, GitHub: philipstarkey).
Good idea, but I think that actually I had better be the one to do it. These repositories on BitBucket were created as part of the agreement that saw Monash University take ownership of the copyright of the first release (back in 2013) and publicly release that code under an open source license. As such, I think it makes sense for me to create the GitHub organisation so that it mirrors what we have here (as I’m still affiliated with Monash).
This issue is also actually really outdated. Most of it is going to be automated by a general purpose tool I’m working on. If everything goes to plan, pretty much everything should make it across to GitHub in one form or another. It’ll be a couple of weeks before that’s ready for testing though!
Original comment by fretchen (Bitbucket: fretchen).
Perfect. I was just wondering about this one. We have now all our machines migrated to labscriptsuite and most likely would like to have a tight integration within github sooner than later :smiley: . And I am happy to helpout whereever I can (when I find the time).
Original report (archived issue) by Philip Starkey (Bitbucket: philipstarkey, GitHub: philipstarkey).
Please note: General discussion on the migration should be kept on the mailing list (see here). This issue is for keeping track of the tasks and our progress.
Regardless of the final decision we make on a destination (the favourite currently being GitHub), there are some things we need to do before we migrate repositories away from BitBucket (forced on us due to the removal of mercurial support). This issue should be used to keep track of them (feel free to add more as we determine what they are).
These are:
Triage/merge all pull requests
Look at the public forks of each component and import them into the new hosting (this will help preserve the history of pull requests, particularly those that were declined or that we decline on BitBucket now because solving the remaining issue is too time consuming at the moment, but we might want to restart the pull request later).
Implement issue #31
import repositories to new host
Export/backup whatever we can from Bitbucket (issues, pull requests, etc) before it is deleted on 31st May 2020
Consider improving the Bitbucket → GitHub issue importer
Import issues to GitHub
Put up Git placeholder repos in all existing Bitbucket repository locations we control, pointing people to the new location (this is so people reading out theses/papers can ‘easily’ find the new code location)
Things to figure out on GitHub (assuming we move there):
How GitHub organisations work (so that all labscript suite repositories are contained together)
Do some tests on the fork/pull request workflow so we get the hang of it and can update instructions accordingly
The use of GitHub pages (possibly for hosting a static HTML repository of the old Bitbucket pull requests)
Integration with readthedocs