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

[QUESTION] Fork status #8

Closed
mrniko opened this issue Mar 22, 2024 · 16 comments
Closed

[QUESTION] Fork status #8

mrniko opened this issue Mar 22, 2024 · 16 comments

Comments

@mrniko
Copy link

mrniko commented Mar 22, 2024

Hello,

Is it an official fork from AWS Elasticache Team?

@madolson
Copy link
Member

madolson commented Mar 22, 2024

Is it an official fork from AWS Elasticache Team?

No, this is just a fork from ex-community members for now. Amazon, and other companies, are aware of what what is going on (AWS employs me).

@viktorix
Copy link

Any reason not to join forces with KeyDB? It has a growing community. They are looking for help with v7.

Snapchat/KeyDB#798

@madolson
Copy link
Member

KeyDB is a pretty significant fork of Redis, and they diverged a long time ago. They don't support a lot of the latest features, and I don't agree with many of their technical directions. The one benefit they have is they have a pretty good community behind it.

@jonas-w
Copy link

jonas-w commented Mar 23, 2024

What is your opinion on the redict fork?

https://redict.io/posts/2024-03-22-redict-is-an-independent-fork/

@ddevault
Copy link

What is your opinion on the redict fork?

https://redict.io/posts/2024-03-22-redict-is-an-independent-fork/

Hey, I'm responsible for the Redict fork. I've been in contact with some of the folks working on this fork (placeholderkv) and have invited them to work on Redict, but we have some differences:

  1. They represent their employers (e.g. AWS) and they don't want to use a copyleft license like the LGPL. This is something neither of us seems prepared to budge on.
  2. They are not interested in moving away from proprietary platforms, i.e. this fork is using GitHub and Discord whereas we're using Codeberg and IRC for now.

I think those were the main differences of opinion between these forks. That said, if their placeholderkv thing gets some traction, Redict will be able to incorporate some changes from this fork, but unfortunately not vice-versa since they don't want to use a copyleft license.

@jonas-w
Copy link

jonas-w commented Mar 23, 2024

What is your opinion on the redict fork?
https://redict.io/posts/2024-03-22-redict-is-an-independent-fork/

Hey, I'm responsible for the Redict fork. I've been in contact with some of the folks working on this fork (placeholderkv) and have invited them to work on Redict, but we have some differences:

1. They represent their employers (e.g. AWS) and they don't want to use a copyleft license like the LGPL. This is something neither of us seems prepared to budge on.

2. They are not interested in moving away from proprietary platforms, i.e. this fork is using GitHub and Discord whereas we're using Codeberg and IRC for now.

I think those were the main differences of opinion between these forks. That said, if their placeholderkv thing gets some traction, Redict will be able to incorporate some changes from this fork, but unfortunately not vice-versa since they don't want to use a copyleft license.

Thanks for the comparison, I just hope there will be not too much duplicate effort with all the redis forks

@mswilson
Copy link

What is your opinion on the redict fork?
https://redict.io/posts/2024-03-22-redict-is-an-independent-fork/

Hey, I'm responsible for the Redict fork. I've been in contact with some of the folks working on this fork (placeholderkv) and have invited them to work on Redict, but we have some differences:

  1. They represent their employers (e.g. AWS) and they don't want to use a copyleft license like the LGPL. This is something neither of us seems prepared to budge on.

[wearing my Amazon hat, as an executive sponsor of the Open Source Program Office]
This is incorrect, at least when it comes to AWS. There are projects that AWS contributes to that are GPL licensed (of all flavors, even including some AGPLv3 contributions to code bases like Grafana). Some companies may have policies that make copyleft licensed projects a complete non-starter, but I don't find Amazon's policies to be that way. There is a lot more for an OSPO at a company like Amazon to do to ensure that all copyleft obligations are continuously met, therefore there are additional reviews and processes required that come with costs. If the community comes to a consensus that copyleft with no CLA is the best path forward (personally speaking, I think it often is a good choice), I'm sure Amazon can find a way to cover those costs ;-). I'd only ask that the community be open to hearing opinions from folks that are clearly wearing an Amazon hat when discussing license choices.

On representing employer interests: I have tried to make it clear both inside Amazon and publicly that @madolson's prior role as a member of the Redis core team was earned by her as an individual, and that giving her the autonomy to do what she believes is best for the Redis community was important to the project (thus important to Amazon). This was the arrangement at the outset when the Redis core team was established in 2020. I have no doubt she has her own opinions about license choice and what's best for the existing community of developers she's working with, and I don't want to speak for her. I only ask that you recognize her voice as her own, and not necessarily representing her employer (unless she explicitly say she is).

  1. They are not interested in moving away from proprietary platforms, i.e. this fork is using GitHub and Discord whereas we're using Codeberg and IRC for now.

It's understandable that a community that was already productive on a platform may want to stick with it. With all the other changes that have occurred, I think you're asking lot to ask this community to change both their license and their productivity tools. I think it's asking a lot to expect them to conform to your values and policies without negotiation or building consensus.

I think those were the main differences of opinion between these forks. That said, if their placeholderkv thing gets some traction, Redict will be able to incorporate some changes from this fork, but unfortunately not vice-versa since they don't want to use a copyleft license.

@ddevault
Copy link

ddevault commented Mar 23, 2024

There have been some breakdowns in communication here, which is not surprising given the Redis community diaspora is a bit shaken right now. I think it's a moot point to try to keep up with discussions that have been split informally across a bunch of proprietary/closed platforms, first Slack, now apparently Discord, etc. I'm glad we're chatting on GitHub now, in public. Let me try to explain my intentions more clearly.

Unlike most of the stakeholders in this fork, I am not aligned with any commercial interests. I do work for a company that uses Redis, but it's not part of our value proposition. Instead my interests here are based on an expressly political free software agenda. The situation with Redis is becoming an epidemic and I intend to step up and do what I can to curtail it; thus my goal here is to establish a fork with as much continuity as possible, as quickly as possible, in a manner which expressly defends the future freedom of this software. Yes, this is politics, but it's politics you're invited to. And, yes, if you decline the invitation, we will continue the politics without you.

I appreciate the open source world that you're coming from, a bit more corporate, a bit less grassroots (the "cathedral", if you're familiar with the metaphor), but it's not really how free software works, it's just a cultural norm you're used to. The software needs to be forked and renamed and something new built around it, so I've organized a community to do that work, but the result is not a new cathedral -- it's a contribution to the bazaar.

I believe that in order to secure a future for this software, and to communicate to other commercial stewards of FOSS projects that pulling this trick does not work, a copyleft license is non-negotiable, and so I have selected that as the license under which I am personally willing to do the part part in establishing a fork, lest the labor I expend in this effort is simply stolen once again. I have started building a community of like minded people to facilitate this work.

I have not sought consensus on the following decisions:

  • I selected the LGPL license, as it is the most appropriate choice to balance the needs of the established Redis community. It uses copyleft to protect the project into the future and creates plenty of room for cloud providers to continue to make use of Redict without any onerous requirements like being forced to share their changes with anyone. (Actually, this was discussed with some stakeholders, namely a few representatives of Linux distros)
  • I named it "Redict". It's a good name and it ends the bikeshed before it begins, allowing the (very labor intensive) work of renaming the project to proceed right away.

Our work proceeds towards building everything up under these assumptions, but there is little to nothing other than this which has been written into stone.

You have all been invited to the table to establish matters of governance, process, tooling, everything. All you have to do is join us! All of the Redis contributors involved in this fork were invited from the start. We're just not waiting for you to get started.

They are not interested in moving away from proprietary platforms, i.e. this fork is using GitHub and Discord whereas we're using Codeberg and IRC for now.

It's understandable that a community that was already productive on a platform may want to stick with it. With all the other changes that have occurred, I think you're asking lot to ask this community to change both their license and their productivity tools. I think it's asking a lot to expect them to conform to your values and policies without negotiation or building consensus.

There is no better time than now to consider these changes, and there's good reason to. But, again, none of is written in stone. Come talk about the infrastructure with us. I don't think any of us are prepared to meet you on Discord, but if you're willing to swallow your pride and join IRC or say hello on the Codeberg issues, we'll be happy to meet you there. Codeberg is just a place to organize the work, much like "placeholderkv" is organizing your efforts here. If the community decides to move it to GitHub, I might hold my nose when it happens, but, it'll happen. That said, I can think of a few people who will have some things to say in the ensuing discussion.

We're ready to welcome you and collaborate, but we're not waiting for you. Tell your bosses that LGPL is the way to go, then come work with us. We should have a release ready next week and then we're going to start encouraging people to migrate, and we would very much like you to be there. Do what's right for this community.

And, hell, if you really insist on using GitHub and Discord and not talking to anyone outside of your clique, just get over the LGPL thing and reuse our code and save yourself a bunch of time and effort redoing everything we've already done and will do over the next few days. That's still mission accomplished, as far as I'm concerned.

@mswilson
Copy link

my goal here is to establish a fork with as much continuity as possible, as quickly as possible

[wearing my own hat as an individual, speaking only for myself]
My belief is that the most continuity comes from having the active contributors involved as quickly as possible. I do not think that asking them to sign up to a political movement in order to participate in the community they already have in one another is fair to them. But I'm an outsider here. I'm not part of the community that has been actively working on Redis. My primary interest here today is that their voices, as individual members of a community, are heard.

I appreciate the open source world that you're coming from, a bit more corporate, a bit less grassroots (the "cathedral", if you're familiar with the metaphor), but it's not really how free software works, it's just a cultural norm you're used to.

Drew, I don't think you know me or my background or what the cultural norms are of the communities that I have been a part of. I'm from the camp that steadfastly used the term "Free Software" as part of an overtly political and ethical movement. I've worked on GNU software and served on the board of directors for SFC long ago. I wish I had more time to devote to those things.

I believe you have taken the steps you have for principled reasons. But they are clearly (explicitly, even) politics. This naturally shifts the social dynamics of your effort, and is why it's clear to me that there are likely irreconcilable philosophical / political differences between your effort and others like this one.

if you're willing to swallow your pride and join IRC or say hello on the Codeberg issues

I sent you a message on Matrix earlier today, and said hi on IRC. But I'm less inclined to stay logged in when you say I need to swallow my pride to use the communication tools that I have loved, and wish I was using more.

Tell your bosses that LGPL is the way to go, then come work with us.

Sigh. With your rhetoric you're not making it easier for me to advocate for this direction.

@madolson madolson mentioned this issue Mar 23, 2024
@ddevault
Copy link

ddevault commented Mar 23, 2024

Sigh. With your rhetoric you're not making it easier for me to advocate for this direction.

You know, you're right, and I apologize for my tone. I am feeling a bit disparaged, because from my perspective, we're here doing a lot of hard work in public and inviting collaboration while there's some discussions happening in private on Slack and Discord to establish this other fork which isn't doing any of the work. If there's a consensus process it feels like we're not a part of it and no one else is invited. It seems like the only reason this fork is not collaborating with us is hubris. I know this isn't the intention, and that things are just in flux right now, but hopefully it explains some of my frustration.

My belief is that the most continuity comes from having the active contributors involved as quickly as possible.

I agree that this is a means of addressing the continuity problem, but specifically, I am trying to address both continuity and preventing this from happening again. Not one or the other but explicitly both. If this fork isn't solving both then we are not going to reconcile our differences.

I believe you have taken the steps you have for principled reasons. But they are clearly (explicitly, even) politics. This naturally shifts the social dynamics of your effort, and is why it's clear to me that there are likely irreconcilable philosophical / political differences between your effort and others like this one.

There is no outcome to the Redis catastrophe, for lack of a better term, which is not politics, I'm afraid. Everything we're doing here is political, and though I understand that there's discomfort in facing that truth, we'll be better off if we agree that something political is going on and we can talk about what political values we care about in that process.

I sent you a message on Matrix earlier today, and said hi on IRC. But I'm less inclined to stay logged in when you say I need to swallow my pride to use the communication tools that I have loved, and wish I was using more.

I'm sorry I missed your messages, I don't use Matrix (but maybe we can consider setting up some discussions there). I just saw your IRC message a few minutes ago. I'm happy to connect there but I don't want to extend this network of private discussions to include PM'ing me over IRC -- we have an IRC channel, #redict, which is open to the public and a great place to connect.

@Conan-Kudo
Copy link
Contributor

I'm sorry I missed your messages, I don't use Matrix (but maybe we can consider setting up some discussions there).

I would personally appreciate Matrix, both as a balance between IRC and Discord experiences (it's a free software platform that gives a lot of what people appreciate from newer chat platforms) and because it's the platform I generally prefer to interact on (I use Matrix for nearly all of my FOSS communication these days).

@ddevault
Copy link

I'm sorry I missed your messages, I don't use Matrix (but maybe we can consider setting up some discussions there).

I would personally appreciate Matrix, both as a balance between IRC and Discord experiences (it's a free software platform that gives a lot of what people appreciate from newer chat platforms) and because it's the platform I generally prefer to interact on (I use Matrix for nearly all of my FOSS communication these days).

Reached out on Matrix via @ddevault:systemli.org. Not super familiar with Matrix so I will need your help setting it up, but let's get it done together.

@bentotten
Copy link
Contributor

TIL IRC survived the death of freenode .. there's an xkcd comic about this somewhere 😂

@Conan-Kudo
Copy link
Contributor

There is now a Matrix room too: https://matrix.to/#/#redict:matrix.org

@kkofler
Copy link

kkofler commented Mar 29, 2024

TIL IRC survived the death of freenode

But then the Freenode fork almost everyone migrated to (Libera.Chat) decided to turn off the Matrix bridge, which has split the community into 2 disconnected fragments. People like me who use IRC can no longer talk to the Matrix users and the other way round. I would strongly recommend staying off Libera.Chat and using one of the IRC networks with a working Matrix bridge, such as OFTC.

@ddevault
Copy link

We also set up a Matrix channel and bridged it directly with IRC, FYI.

naglera pushed a commit to naglera/placeholderkv that referenced this issue Apr 8, 2024
…is missed cases to redis-server. (#12322)

Observed that the sanitizer reported memory leak as clean up is not done
before the process termination in negative/following cases:

**- when we passed '--invalid' as option to redis-server.**

```
 -vm:~/mem-leak-issue/redis$ ./src/redis-server --invalid

*** FATAL CONFIG FILE ERROR (Redis 255.255.255) ***
Reading the configuration file, at line 2
>>> 'invalid'
Bad directive or wrong number of arguments

=================================================================
==865778==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x7f0985f65867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    valkey-io#1 0x558ec86686ec in ztrymalloc_usable_internal /home/ubuntu/mem-leak-issue/redis/src/zmalloc.c:117
    valkey-io#2 0x558ec86686ec in ztrymalloc_usable /home/ubuntu/mem-leak-issue/redis/src/zmalloc.c:135
    valkey-io#3 0x558ec86686ec in ztryrealloc_usable_internal /home/ubuntu/mem-leak-issue/redis/src/zmalloc.c:276
    valkey-io#4 0x558ec86686ec in zrealloc /home/ubuntu/mem-leak-issue/redis/src/zmalloc.c:327
    valkey-io#5 0x558ec865dd7e in sdssplitargs /home/ubuntu/mem-leak-issue/redis/src/sds.c:1172
    valkey-io#6 0x558ec87a1be7 in loadServerConfigFromString /home/ubuntu/mem-leak-issue/redis/src/config.c:472
    valkey-io#7 0x558ec87a13b3 in loadServerConfig /home/ubuntu/mem-leak-issue/redis/src/config.c:718
    valkey-io#8 0x558ec85e6f15 in main /home/ubuntu/mem-leak-issue/redis/src/server.c:7258
    valkey-io#9 0x7f09856e5d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s).

```

**- when we pass '--port' as option and missed to add port number to redis-server.**

```
vm:~/mem-leak-issue/redis$ ./src/redis-server --port

*** FATAL CONFIG FILE ERROR (Redis 255.255.255) ***
Reading the configuration file, at line 2
>>> 'port'
wrong number of arguments

=================================================================
==865846==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x7fdcdbb1f867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    valkey-io#1 0x557e8b04f6ec in ztrymalloc_usable_internal /home/ubuntu/mem-leak-issue/redis/src/zmalloc.c:117
    valkey-io#2 0x557e8b04f6ec in ztrymalloc_usable /home/ubuntu/mem-leak-issue/redis/src/zmalloc.c:135
    valkey-io#3 0x557e8b04f6ec in ztryrealloc_usable_internal /home/ubuntu/mem-leak-issue/redis/src/zmalloc.c:276
    valkey-io#4 0x557e8b04f6ec in zrealloc /home/ubuntu/mem-leak-issue/redis/src/zmalloc.c:327
    valkey-io#5 0x557e8b044d7e in sdssplitargs /home/ubuntu/mem-leak-issue/redis/src/sds.c:1172
    valkey-io#6 0x557e8b188be7 in loadServerConfigFromString /home/ubuntu/mem-leak-issue/redis/src/config.c:472
    valkey-io#7 0x557e8b1883b3 in loadServerConfig /home/ubuntu/mem-leak-issue/redis/src/config.c:718
    valkey-io#8 0x557e8afcdf15 in main /home/ubuntu/mem-leak-issue/redis/src/server.c:7258
    valkey-io#9 0x7fdcdb29fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Indirect leak of 10 byte(s) in 1 object(s) allocated from:
    #0 0x7fdcdbb1fc18 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164
    valkey-io#1 0x557e8b04f9aa in ztryrealloc_usable_internal /home/ubuntu/mem-leak-issue/redis/src/zmalloc.c:287
    valkey-io#2 0x557e8b04f9aa in ztryrealloc_usable /home/ubuntu/mem-leak-issue/redis/src/zmalloc.c:317
    valkey-io#3 0x557e8b04f9aa in zrealloc_usable /home/ubuntu/mem-leak-issue/redis/src/zmalloc.c:342
    valkey-io#4 0x557e8b033f90 in _sdsMakeRoomFor /home/ubuntu/mem-leak-issue/redis/src/sds.c:271
    valkey-io#5 0x557e8b033f90 in sdsMakeRoomFor /home/ubuntu/mem-leak-issue/redis/src/sds.c:295
    valkey-io#6 0x557e8b033f90 in sdscatlen /home/ubuntu/mem-leak-issue/redis/src/sds.c:486
    valkey-io#7 0x557e8b044e1f in sdssplitargs /home/ubuntu/mem-leak-issue/redis/src/sds.c:1165
    valkey-io#8 0x557e8b188be7 in loadServerConfigFromString /home/ubuntu/mem-leak-issue/redis/src/config.c:472
    valkey-io#9 0x557e8b1883b3 in loadServerConfig /home/ubuntu/mem-leak-issue/redis/src/config.c:718
    valkey-io#10 0x557e8afcdf15 in main /home/ubuntu/mem-leak-issue/redis/src/server.c:7258
    valkey-io#11 0x7fdcdb29fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: 18 byte(s) leaked in 2 allocation(s).

```

As part analysis found that the sdsfreesplitres is not called when this condition checks are being hit.

Output after the fix:


```
vm:~/mem-leak-issue/redis$ ./src/redis-server --invalid

*** FATAL CONFIG FILE ERROR (Redis 255.255.255) ***
Reading the configuration file, at line 2
>>> 'invalid'
Bad directive or wrong number of arguments
vm:~/mem-leak-issue/redis$

===========================================
vm:~/mem-leak-issue/redis$ ./src/redis-server --jdhg

*** FATAL CONFIG FILE ERROR (Redis 255.255.255) ***
Reading the configuration file, at line 2
>>> 'jdhg'
Bad directive or wrong number of arguments

---------------------------------------------------------------------------
vm:~/mem-leak-issue/redis$ ./src/redis-server --port

*** FATAL CONFIG FILE ERROR (Redis 255.255.255) ***
Reading the configuration file, at line 2
>>> 'port'
wrong number of arguments
```

Co-authored-by: Oran Agra <oran@redislabs.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants