 situation I'd agree to a more conservative approach.

I won't lie though, I really have limited time and won't be around with this frequency forever. My schedule and mental health won't sustain it. My concern with a smaller port is that there is still a barrier to entry for any new maintainer and a piecemeal port means a long-term investment that I'm not sure anyone currently contributing has in them. Maybe that's unfounded, but I'd like to err on the side of caution w.r.t. active maintainership. I know that if all we need to do for new features is watch redis-py for changes and port them over, there's a much much greater likelihood of keeping this library moving. The same can go for the parser logic and the implemented clients.

For connection-related bugs we'll still need to do triage, but thankfully the connections implementation in this PR is easier to grok than the original version so we've still got a win there.

I will defer (a bit) to the will of the community here, with a grain of salt. At the end of the day I want to make we do right by our community and I do think the best way to do that is to keep the codebase maintainable and up-to-date, so whatever we decide to do, let's just be sure we're achieving that goal.
<issue_comment>username_0: Very nice! I think if/when this PR merges, we can look at what integrating this would mean for our testing.
<issue_comment>username_3: Any news?
<issue_comment>username_0: Hey @username_3 - I wanted to wait a few days before moving forward, in the event folks from the community wanted to weigh in.

I'm also working on revamping the documentation and providing a migration guide so that when we land this change there's ample resources to support developers.
<issue_comment>username_3: Awesome, it's completely understood. I'm a bit paranoid the project will go stale again so was just pinging. If you need any help let me know.
<issue_comment>username_2: I will share my thoughts in a day or two, too much complex work right now.
<issue_comment>username_0: Hey @username_2 just wanted to check in. I respect that you have work and a life but I'd like to get your input before we move in any direction with this PR. I'd also like to avoid this project becoming stale again.
<issue_comment>username_2: Ok guys, first of all thank you for your contribution to the project.
But I don't think this is the way to go for aioredis, especially when
there already is a redis-py port to asyncio — aredis.

I know that internals of aioredis is hard to understand and I acknowledge
that it must be revised, with current connections management design
(and some other parts) it gets hard to extend the library, especially
with new Redis 6 protocol.

In my opinion we should do the following. First, current issues need to be addressed
to differentiate simple issues/tasks that do not require internals hacking
and are straightforward to fix/implement and would lead library to 1.4 release.
Next, connection management should be redesigned to be ready for new
Redis features which should bring us to aioredis version 2.

I don't want you guys to step back I appreciate your work and I will
help you understand all those internals with TODOs and other stuff
so we can move aioredis to new major release.
I would like to keep nice aioredis features and also make easier to support and develop,
just not with a such a dramatic change.
<issue_comment>username_1: there already is a redis-py port to asyncio — aredis.

aredis is not exactly maintained. I looked around for async redis clients for awhile, and none of them were exactly maintained, so I stuck with aioredis simply because it had the most stars and I thought maintainership would resume under the aio organization. And it did!

Like the synchronous Redis-py lib, we could make aioredis the sole async redis client for the entire Python ecosystem because we 1. have maintainership resumed and 2. have a large community backing. Sorry if that sounds political/inorganic (in growth), but based on everyone's async benchmarks and a different issue where someone said aioredis is 3 times slower than redis-py but the speeds are the same using this port, I think going down this PR's path is also OK.

Yes alternatives are great, but performance and maintainership is key to every library, and none of them have the latter, including aioredis for a long time.
<issue_comment>username_2: It is great that we have such benchmarks so it is possible to identify slow code, but I believe that pipeline/transaction issues can be fixed in terms of aioredis code maybe even reusing redis-py parts/ideas.
<issue_comment>username_4: To give an aioredis users' perspective: It's no secret our community lacks a sustainable, updated, high quality, performant async redis library. I have to give kudos to @username_0 as he has a sound plan which I for one believe is the quickest (and time may prove, the only sustainable) way to solve this.

I've been closely following and it's concerning our limited resources within the community may be wasted on a sunk cost problem- @username_2 has done some amazing work over the years but aioredis' technical debt may be so high that we face a very real danger of project death as a rewrite is likely beyond the scope of what anyone here can sustainably contribute, even collectively. **_This is a worst case scenario for everyone involved._**

The advantages of a redis-py port are very clear and will only get more advantageous as time moves forward, especially as current aioredis falls more behind.
<issue_comment>username_2: Go on with this PR just rename the library and repository to `aioredis-py` so that difference and changes between `aioredis` and releation to `redis-py` is clear and honest. I realized that I would not have enough time to drive the development and it also makes me sad that no one wants to invest time to sort out lib's internals. Its all on you now. I step back. Good luck.
<issue_comment>username_0: @username_2 - I'm sorry to see you step back but I respect and appreciate your honesty.

@username_4 - Thank you for the kind words of support.

I've taken a few days to respond because I wanted to step back and reflect on the long discussion we've had in this PR. I still do believe this is the correct path forward for now, and with the blessing of the community I will continue to push this PR forward. There is still a lot of work to be done on the documentation, which I'm hoping to have done in the coming weeks. At that point, I think we could target a `v2.0.0a1` release with this port.

As @username_2 has requested, once this PR is merged, I will also look at renaming the repository to `aioredis-py` to better reflect that this will be a running asyncio-based port of `redis-py`, rather than a custom implementation, as `aioredis` was.

At the end of the day, everyone here wants to see this community and library not only survive, but flourish. I look forward to continued collaboration as we continue our work.
<issue_comment>username_1: Will the package be renamed as well? @username_0
<issue_comment>username_0: No, I think we’d follow the redis-py convention (yet again). The repo is
`aioredis-py` and the package is `aioredis`.
<issue_comment>username_3: @username_0 Any ETA on first release?
<issue_comment>username_0: I'm hoping to finish up documentation this weekend, then perhaps get an alpha release out by end of next week!

Thanks everyone for your continued patience. I do believe this will enable a much faster iteration cycle moving forward, but it's a Big Change :tm: to get pushed through.
<issue_comment>username_5: Gonna +1 @username_2 here and say it seems like the better place to do this is [aredis](https://github.com/NoneGG/aredis), which is already an asyncio port of `redis-py`. 

To @username_1's point, `aredis` is open source too, so if it's not exactly maintained then you can... help maintain it. But doesn't really make sense to me to have two open source asyncio redis libs that are both just `redis-py` ports. Lots of talk about how "this is the easier way", but seems like the easiest way would've been to just help maintain `aredis`. This on the other hand is duplication of effort already done in the `aredis` lib.

If there is more than one way to solve the problem, having a "sole" asyncio redis lib for python sounds like a bug, not a feature