[nerdponx]

I am very much in favor of making contributions easier, but doesn't Github seem short-sighted?

It seems to be veering in a direction of some kind of weird cloud IDE thing, which is fine in and of itself, but what happens if/when it is no longer suitable as a general dev platform?

Python has full and total control over bugs.python.org, whereas Github is a proprietary platform. Might it not be a mistake to cede control over the issue tracker? It seems like the main problem in the article is the CLA-signing process anyway, not BPO.

[da39a3ee]

It’s fantastic that Python is moving to github. It’s so frustrating that projects like django, emacs, python, etc have insisted on using these antiquated development workflows and that some of the old timers even insist that they are better and that github is for “mindless kids who put PRs up thoughtlessly”.

Sounds like you should go and read PEP 581 before criticizing their decision!

[nerdponx]

I admit I only skimmed the PEP, and I think their rationale is mostly sound. It's a concession to practicality, given the surprisingly limited resources of the Python core development group.

I certainly don't think the problem with GH is that it's for "mindless kids". I hate mailing lists and I hate old-school bug trackers that don't support code markup or rich linking. In the short and medium term, I'm grateful that things will become a lot easier. The long term is what worries me.

But I'm also probably being a bit too cynical. If and when in 5-10 years they want to move off of GH, they will be able to do so. I'm not envisioning some kind of catastrophic "rug pull" from Microsoft where suddenly the Github API disappears and the issue tracker becomes locked-in.

[da39a3ee]

Right, exactly. It's moving to issues and PR-based workflows that's the important thing. If GitHub becomes problematic in the future, they can switch to some other provider of similar functionality, and all the millions of programmers around the world who are familiar with issues and PR-based workflows can follow them.

I am personally someone who only knows PR-based workflows and is somewhat ignorant about other workflows. There are the mailing lists and old-school bug trackers which I am pretty sure I don't like. But I know that several (most/all?) big US tech companies use non-PR-based workflows via tools like Gerrit and Phabricator. I am not at all clear yet on the pros and cons of those workflows versus PRs.

[da39a3ee]

> “mindless kids who put PRs up thoughtlessly”.

Sorry, I wasn't accusing you of holding that position. Some embarrassing idiot on the emacs-devel mailing list said it.

[shkkmo]

Github isn't setup to stop your from moving your project to other hosting providers. You can export GitHub to other git hosting setups (like a self-hosted GitLab.)

[mjw1007]

Does github provide a way to redirect the URLs for individual issues to the corresponding issues on a new bugtracker?

[shkkmo]

Probablu not, but you could probably find or write a script to close all the github issues with a final comment linking to the duplicated issue on the new tracker.

[ReactiveJelly]

Including the issues?

[shkkmo]

Yes, and other things, see: https://docs.gitlab.com/ee/user/project/import/github.html