Skip to content
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

PEP 581, 588: Split GitHub migration rationale and plan into two separate PEPs #1013

Merged
merged 1 commit into from Apr 30, 2019

Conversation

Projects
None yet
8 participants
@warsaw
Copy link
Member

commented Apr 26, 2019

No description provided.

@mariatta-bot

This comment has been minimized.

Copy link

commented Apr 26, 2019

:robot_face: Mariatta was mentioned, but she's out of open source from March 18th to May 9th, 2019 . Be aware she might not get to this until after PyCon US.
(I'm a bot)

people who aren't already familiar with the code base.
There is an open discussion about moving the source code of bpo to
GitHub [#]_. If the source code of bpo does move to GitHub, it will
become difficult to update patches from upstream. But as long as it

This comment has been minimized.

Copy link
@berkerpeksag

berkerpeksag Apr 26, 2019

Member

This isn't a huge problem. Roundup has recently added builtin REST interface. We can start to port our GitHub integration to use it. I don't think we are relaying on our fork's customizations too much. As always, I'm volunteering to do this work.


Issues with Roundup / bpo
-------------------------

- Less than five people maintain bpo. Some of them are core developers.

- It is in Mercurial. Without any CI available, it puts heavy burden on the few
existing maintainers in terms of reviewing, testing, and applying patches.
- The upstream Roundup code is in Mercurial. Without any CI available,

This comment has been minimized.

Copy link
@berkerpeksag

berkerpeksag Apr 26, 2019

Member

Personally, I don't see how this is a problem here. pip install supports installing from Mercurial repositories and its testing suite isn't that hard to run. Plus, as I said below, our Roundup instance can easily be moved to GitHub.

upstream. But as long as it is in Mercurial, it is difficult to maintain
and onboard new contributors.
- In its current state, the project is not equipped to accept lots of
contributions from people who aren't already familiar with the code

This comment has been minimized.

Copy link
@berkerpeksag

berkerpeksag Apr 26, 2019

Member

I find the most complicated part of the installation process is installation of our Roundup fork. Once we get rid of our fork, it won't be harder than installing python.org.

I'd share my INSTALL document here, but unfortunately I left it in my computer in my hometown. But you can take a look at the Docker image at https://github.com/python/docker-bpo. It can be simplified by using Docker Compose.


- The user interface needs an update and redesign. It will require UX/UI research
to keep it up to date with current web standards, including accessibility.

- Email address is exposed. There is no choice to mask it.
- Users email addresses are exposed. There is no option to mask it.

This comment has been minimized.

Copy link
@berkerpeksag

berkerpeksag Apr 26, 2019

Member

Roundup can be modified to mask usernames and/or email addresses. See https://issues.roundup-tracker.org/issue2551034 for example: Usernames masked as [hidden] there.

contributors and maintainers, while not having to jump from one interface to another.
By using GitHub issues, where the CPython source code is currently
hosted and where pull requests are taking place, we'll be providing
consistent experience to contributors and maintainers, while not

This comment has been minimized.

Copy link
@berkerpeksag

berkerpeksag Apr 26, 2019

Member

We are not the only project that uses a different issue tracker while using GitHub to host its source code. Some projects (SQLAlchemy) even use GitLab for issue tracking.

@berkerpeksag

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

Barry told me to post my email in python-committers here. I'll try to summarize it.

I'm strongly against using GitHub Issues because of the following reasons:

@brettcannon

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

@berkerpeksag can I request you tweak the tone of your comment? It's coming off as unnecessarily hostile.

@berkerpeksag

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

@brettcannon which part of my comment do you think is hostile?

@brettcannon

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

@berkerpeksag primarily your first bullet point. While you might think GitHub doesn't listen, I don't think that's true but you state it like it's a universal truth. And your last sentence in that point very much comes off as a dig as well. And just because they don't announce features before they launch doesn't mean they don't listen (I say the same things to my users at my work because I know if I over-promise and under-deliver I'm the one they will yell at, so it's easier to just not say anything until something is already released).

@berkerpeksag

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

@brettcannon I gave two examples from my own experience that they didn't listen (both issues can be classified as bug) in the second bullet point. I'd be happy to combine the first two bullet points if you think that would make my comment better.

And just because they don't announce features before they launch doesn't mean they don't listen

True, but none of my reports were actually feature requests and I definitely don't expect constant communication from them. I don't think it's unreasonable to expect a response like "we are going to fix this in X months" a year after I reported it in a place where they were created to gather feedback from the community.

@Mariatta Mariatta merged commit b393d4b into python:master Apr 30, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Mariatta

This comment has been minimized.

Copy link
Member

commented May 1, 2019

Github doesn't listen to its users feedback. When you reach out to them, you usually get a "we can't say whether we are going to do this or not" response. Instead, they are busy with adding more important features.

Sorry you had terrible experience, but I think you're generalizing the situation. Personally I've had good experiences with GitHub. Whenever I had issues and questions, they answered within 24 hours. So I think saying "GitHub doesn't listen" doesn't sound fair, or maybe I'm really lucky.

See issues Allow for the tweaking of the commit title template (or at least to use GH over #, Don't populate (or make it optional) intermediate commits automatically in commit message and can the preserve the author of the original commit in the squash merge? for more examples. Note that the last one is actually a bug.

I feel these issues are not related to GitHub-as-issue-tracker, and not the problems that PEP 581 trying to solve, so it seems like a distraction to current topic. I also don't feel the last one as a bug. If miss-islington actually did the work to backport and create the PR, it can earn the credit IMO. The others problems you mentioned here, we've tried to help solve by miss-islington's automerge. If core devs still chose not to use the automerge feature, then I don't know what to say to that...

I'd rather spend my free time to maintain our infrastructure than trying to workaround a company's product.

You're definitely free to choose how you spend your free time. Roundup itself is not going away. It's not officially maintained by Python core developers, although several core developers like yourself maintain it. (thank you!!). I can understand if you're not interested in maintaining other workarounds like bedevere, miss-islington. However these projects are on GitHub and open source, and we already have quite a number of contributions to them from non core developers, so I don't feel there will be an issue.

We are trying to workaround GitHub's lack of features by creating custom tools.

Personally, I think that's the purpose of the APIs, and I actually think it is great that GitHub has a set of nice features, and we can still further customize the experience by building our own tools by utilizing their APIs.

@warsaw warsaw deleted the warsaw:github-migration branch May 1, 2019

<https://discuss.python.org/t/proposal-create-bug-triage-team-on-github/992/5>`_
for us to create a "bug triage" team on GitHub to help with closing
issues, notifying the appropriate parties, as well as applying labels
to issues and pull requests. We can grant the "write" permission to

This comment has been minimized.

Copy link
@ammaraskar

ammaraskar May 15, 2019

This should be updated to reflect that Github now has a triage level permission https://discuss.python.org/t/pep-581-using-github-issues/535/36?u=ammaraskar

This comment has been minimized.

Copy link
@pradyunsg

pradyunsg May 15, 2019

Contributor

It's a private beta though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.