Closed gvanrossum closed 7 years ago
I vote to keep this repo as is until CPython is on GitHub because I too prefer managing issues and PRs here.
Will you then also merge everything back to 3.5 and from there to the 3.6+3.7 branches? I'm honestly fine with issues here, but changes are getting more and more painful.
Sure, I'll sync all repos/branches.
Sounds good.
OK, so let's keep this repo for stuff that can/should go into 3.5, and let's have the 3.6-only stuff in the 3.6 branch.
Cool. FWIW I managed to merge a few of PRs today and will do a few more. Making sure CPython and and this repo are synced was a bit painful though.
Anyways, I'll close this issue for now. Let's close this repo once CPython is migrated to GH.
Saw all your activity. Thanks!!
NP! I'll soon submit a PR for https://github.com/python/asyncio/issues/372. Would appreciate a quick review...
(where quick means it would be cool if you could just glance over it ;)
Hi,
Good idea to close this repository. However, at least to me, we have also some interesting wiki pages, herited from Google code repository, especially, this page: https://github.com/python/asyncio/wiki/ThirdParty
We might integrate this wiki page in asyncio-doc repository: https://github.com/asyncio-doc/asyncio-doc
Ok for you, or you have another idea ?
Have a nice day.
I think it's time for us to re-open this discussion. I vote to close this repo and focus the development in the official CPython repo/bug tracker.
Syncing commits and issues back and forth is annoying, and I think it's also time for us to officially drop support of Python 3.3.
I concur, especially now that CPython is on GitHub so the argument is now moot that asyncio gains a lower barrier to entry by being a separate GitHub repository.
(Just to add: before closing this repo, I'll spend some time to merge all outstanding PRs, and possibly migrate open issues to bpo).
+1
Will asyncio for Python 3.3 be released at PyPI in the future?
If not, I want to merge python/cpython#232 .
IIUC we will not release any new asyncio versions through PyPI, so that PR sounds good to me. But Yury's the boss here.
OK, I guess it's decided. We'll be closing this repo. By "closing" I mean we'll leave only a README file in it, redirecting people to bpo & GH/cpython.
If not, I want to merge python/cpython#232 .
Please give me some time to deal with this repo, I'll probably be doing some merges. We'll merge your PR after that.
I see. Thanks.
@GMLudo: "However, at least to me, we have also some interesting wiki pages, herited from Google code repository, especially, this page: https://github.com/python/asyncio/wiki/ThirdParty We might integrate this wiki page in asyncio-doc repository: https://github.com/asyncio-doc/asyncio-doc "
I like this idea: would you mind to create a pull request? asyncio-doc is more general than CPython and asyncio, so it's the perfect new home for these docs.
Synchronization between cpython and asyncio projects never worked well. One project was always outdated, but not always the same was outdated :-) Since there is no more release on PyPI since 2 years, keeping two distincts projects doesn't make sense anymore.
The new CPython workflow will allow to cleanup asyncio (@methane already proposed a change to start to cleanup "compat.py"!), since branches are better separated in the dev workflow. I don't think that it's still important to have exactly the same asyncio code base in each CPython branch.
By "closing" I mean we'll leave only a README file in it, redirecting people to bpo & GH/cpython.
Oh ok, in this case, go for it.
Slowly, we should move PR and issues to CPython, and later close/reject outdated PR and issues.
When this project will no more have PR, issues nor documentation in the wiki, maybe we can discuss to remove it from GitHub. Or maybe it's better to keep it for history, but block new PR and issues?
Or is it already possible to technically keep existing PR and issues but block creation of new ones?
Or is it already possible to technically keep existing PR and issues but block creation of new ones?
No. We can only tell people to not open new ones. I don't think it's going to be an issue.
@1st1 Instead of blowing away master
perhaps leave the README in a different branch and set that new branch to the default one? Would allow for keeping all PRs for the time being in addition to redirecting users.
@1st1 Instead of blowing away master perhaps leave the README in a different branch and set that new branch to the default one? Would allow for keeping all PRs for the time being in addition to redirecting users.
Good idea, I'll try it. As for PRs: 50% of them can be just closed; 50% will be moved to gh/cpython soon.
OK, the repo is now in a closed state, see https://github.com/python/asyncio.
Yep I agree about closing this repo. Also should you close all new comments on issues and PR's here too or no?
@AraHaan Might be useful to keep issues for legacy reasons so I think for the sake of visibility they should be left open. Sadly you can't disallow new issues without making existing issues invisible.
We'll migrate some issues to bpo.
@haypo @1st1 @asvetlov
While this repo is still in sync with the 3.5 branch of the cpython Hg repo, the default branch (soon to become the 3.6b1 release branch) is deviating more and more, e.g. @haypo added something to the 3.6 branch only about logging and @1st1 added support there for async generators (PEP 525).
I think it's becoming more and more complex to make changes in this "upstream" repo, then copy them to the 3.5 branch using the update_stdlib.sh script, and from there merge into the 3.6 branch. With the release branch it's going to be even more complicated.
Advantages of this repo are that it has its own issue tracker, which I like more than bugs.python.org, and I like GitHub PRs more than the bugs.python.org patch mechanism; but the merge-back workflow is really tedious.
I propose to do the following once the 3.6b1 release branch exists (or right now):
Thoughts?