-
-
Notifications
You must be signed in to change notification settings - Fork 369
Migrate to Github #1410
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Original comment by Sylvain Hellegouarch (Bitbucket: Lawouach, GitHub: Lawouach): Hey Jason, I'm all for it! I think there had been other people stating they were for it too. As long as we manage to keep our history and we don't kill the bitbucket repo (keep it as a read-only to github for a long while so people can still refer to it). Thanks for the proposal and offering to undertake the task. |
Original comment by Joel Rivera (Bitbucket: cyraxjoe, GitHub: cyraxjoe): @bhch we currently maintain a github mirror: https://github.com/cherrypy/cherrypy Would you mind on expressing the reason behind preferring Mercurial over Git for a project that you don't actively contribute to? Just curios, do you maintain some sort of fork? Personally I like Mercurial. But pragmatically GitHub is where the conversation is happening most of the time and if the move increase the engagement into the project (which I believe it will) then the change is justified. Also, we don't really benefit for any peculiarity from mercurial. So the preferences is mostly a matter of personal taste or philosophy but from the perspective of the project I would always prefer the alternative that add less friction for contribution. Lot of people already knows git and it has become the defacto for main stream open source. |
Original comment by Konstantin Molchanov (Bitbucket: moigagoo, GitHub: moigagoo): Just a sidenote: after moving to GitHub, you could add a Gitter chat to the repo that would replace IRC. Gitter provides a convenient way to engage in a discussion with the developers and community members. It offers markdown, history, and email notifications, which really makes IRC pale in comparison. Although I like hg more, I totally support the move to GitHub. I agree with Joel—personal tastes should not affect project-wide decisions. |
Original comment by Nicklas Börjesson (Bitbucket: nicklasb, GitHub: nicklasb): Yeah, this sounds great! I agree on basically everything said here: +1 WRT mercurial, an open source project should aim to lower the bar for participation, and it is not like GIT is evil, closed source and proprietary +1 using gitter, it is really usable. Actually very usable. +1 keeping the bitbucket repo read-only. +1 Creating an organization at github. However, isn't /cherrypy already an organisation? WRT to moving issues, yeah if that works, great. It would be good if the issues on bitbucket could get a not that they have been moved at the end. |
Original comment by Nicklas Börjesson (Bitbucket: nicklasb, GitHub: nicklasb): Well, it is sort of that we now instead expect people to have google, IRC and bitbucket accounts instead. I'd rather not involve IRC in any way, seems like that would just complicate stuff. Gitter is very de facto on github. And rightfully so IMO. |
Original comment by Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco): @Lawouach or @cyraxjoe, do you know who administers the Github CherryPy org? I'm not a yet a member. Could you add me as an admin so I might create test repos and test migrating the issues? Also, there's a problem with the existing mirror - it already has pull requests against it, and since Github uses the same number sequence for pull requests and issues, it won't be possible to migrate the existing set of issues from bitbucket to the existing Github mirror and retain numbering (which is highly useful). I recommend wiping (or renaming/archiving) the existing Github repo and creating a new one, resetting the issues for a clean migration. Who is it that maintains the current Github mirror? How is that accomplished (with hg-git perhaps)? I'd like to see if I can make a clone that links to both Git and Mercurial repos as well. |
Original comment by Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco): Working around issue 42, I now am blocked by issue 65:
|
Original comment by Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco): @niklasb I hadn't noticed that before - namely that the URL appears to include the issue number but also three additional digits. Perhaps you're right and the URL is corrupted and can be corrected client side. I also observe that the migration completed the migration of issue #559 (see github). How is that even possible? Perhaps the 558 in 558353 was simply a coincidence and that six digit number is otherwise arbitrary. |
Original comment by Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco): Confirmed - the 558 prefix was a coincidence. If I print the status URL in the migration script, here's what I see.
|
Original comment by Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco): After addressing issue 65, I'm now getting another error:
|
Original comment by Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco): I ran again with this branch, and as you might expect, it failed with the same error from before.
No mention of rate limiting, though. Perhaps that's because it failed on the check URL. Next step - I'll try to devise something to watch the rate-limiting headers and slow down when approaching the limit. |
Original comment by Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco): Darn. So close. After applying retry on rate limiting, the process got further (though without triggering the retry logic), but still failed with a 403:
So it seems that it's not just failing with 404 responses on the status check but also 403 responses. Still, it was so close. Maybe another run will succeed. |
Original comment by Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco): Aha, so there was a bug in the ratelimit detection, now fixed. With any luck, that will see the migration through. |
Original comment by Nicklas Börjesson (Bitbucket: nicklasb, GitHub: nicklasb): Not sure how to interpret that, but are you making the actual move now of are you just finding out if it is working? |
Original comment by Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco): The last migration (cherrypy-mig-test-17) migrated successfully, with only one stall in the middle (waiting for rate limit to clear worked). But then I realized that I was doing the migration with my Github account, which has the unfortunate effect of making every issue and comment assigned to me. I don't want that, so I'm running the migration again, this time with the https://github.com/bb-migration account (something I created to migrate setuptools). |
The migration is complete. CherryPy can now be found at https://github.com/cherrypy/cherrypy. I'll be doing some additional cleanup work like:
|
@jaraco How did you manage to keep the same issue IDs in BitBucket and GitHub? |
@ngrilly - the bitbucket_issue_migration project is designed to do that. It does it by first requiring that the target repo have no existing issues. It then creates new issues in github, inserting dummy issues if there are gaps in the bitbucket numbering, and then lets github assign the numbers, which usually align with the numbers from bitbucket. |
@jaraco Thanks. Nice hack :-) |
Originally reported by: Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco)
In order to be more visible and friendly to more contributors, CherryPy should consider moving to Github.
Github is the canonical and preferred hosting for most open source projects.
I'm willing to help with the process, but I first want to get the nod from @cyraxjoe and @Lawouach. Also, we'll need to create a CherryPy org (if there's not a better one to host it).
I propose migrating the existing issues to Github using https://github.com/jeffwidman/bitbucket-issue-migration or one of its many forks. I'm happy to test and execute that.
The text was updated successfully, but these errors were encountered: