Hacker News Reader

Comment by taleinat | Hacker News Reader

(Python core dev here.)

Python is well into the process of transitioning from bugs.python.org to GitHub issues. See PEP 581[1] for the rationale. Ezio Melotti is leading the project, and one may follow the progress on the psf/gh-migration GitHub repo[2] where the work is being managed (including specifically the Projects tab).

Hopefully, that should help make things smoother and more accessible for potential contributors.

[1] https://www.python.org/dev/peps/pep-0581/

[2] https://github.com/psf/gh-migration

View on HN

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.

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!

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.

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.

> “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.

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.)

Including the issues?

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

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

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.

Without meaning to seem hostile, what about comments like this one:

https://news.ycombinator.com/item?id=29837405

Please drop the stupid CLA crap. You don't need it, and you need to fire whatever idiot lawyer told you that you did.

Talking aggressively like this is exactly the reason why we need CLAs.

CLAs are the reason for the harsh language. There's no reason to make contributors create and link a half-dozen accounts and read seven hundred pages of legalese to contribute to your project. It's a real barrier to contributions (see: the linked article), not to mention the time projects waste setting up these broken automated CLA systems, just to justify some lawyer getting a paycheck.

What do comments, aggressive or otherwise, have to do with a licensing agreement?

Are you confusing CLAs with CoCs?

Reply on news.ycombinator.com