go-zookeeper
go-zookeeper copied to clipboard
samuel
Consolidate Forks?
@msolo @multicharts and others: You seem to be maintaining various forks with several fixes (e.g zk re-auth). Would anyone of you consider to contribute your patches back here? Right now it is pretty confusing which fork is promising one.
Thans for considering :)
(Sorry for filing that request here. Most forks have their issue tracker disabled).
I've tried to upstream before, so I'm clearly fine with it.
On Wed, Jul 12, 2017 at 2:35 PM, Stephan Erb [email protected] wrote:
@msolo https://github.com/msolo @multicharts https://github.com/multicharts and others: You seem to be maintaining various forks with several fixes (e.g zk re-auth). Would anyone of you consider to contribute your patches back here? Right now it is pretty confusing which fork is promising one.
Thans for considering :)
(Sorry for filing that request here. Most forks have their issue tracker disabled).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/samuel/go-zookeeper/issues/165, or mute the thread https://github.com/notifications/unsubscribe-auth/AE19BGm0stwTKfbU_07VptWPHVGOxUpaks5sNTwzgaJpZM4OWPGB .
It seems that the upstream is (currently?) a bit dead.
The multicharts fork which I'm maintaining at work is just a collection of bug fixes from other forks, plus a couple of new command line tools.
I'd be happy to switch to another fork, if it would be proposed as a well maintained alternative to the upstream :)
Sorry for the late reply. I too am totally in favor of consolidating forks. We invest quite a bit in zookeeper (java server as well) so it would be good to collaborate on a good, stable location.
On Sun, Jul 23, 2017 at 10:12 AM, Victor Gaydov [email protected] wrote:
It seems that the upstream is (currently?) a bit dead.
The multicharts fork which I'm maintaining at work is just a collection of bug fixes from other forks, plus a couple of new command line tools.
I'd be happy to switch to another fork, if it would be proposed as a well maintained alternative to the upstream :)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/samuel/go-zookeeper/issues/165#issuecomment-317267690, or mute the thread https://github.com/notifications/unsubscribe-auth/AE19BBFX4fmSViFZ8KQZcPqSkN6GHEp-ks5sQ38RgaJpZM4OWPGB .
Fyi, https://github.com/gofrs/help-requests/issues/28
Mesosphere has a public fork with some commits: https://github.com/mesosphere/go-zookeeper
FYI, I am considering moving my zookeeper-3.5 and go-zookeeper forks to a separate org, but that seems to more like proliferation. (see https://xkcd.com/927/)
I'm open to other ideas on how to collaborate on a good canonical fork.
I am actively going to be adding the 3.5 reconfigure APIs to this library in my own fork (dev branch). I intend on proposing a PR to this repo when its done but based on this thread and activity am not sure if it will be merged. is is possible to start an open org for something like this situation? I would be fine being a maintainer or reviewer of said org.
https://github.com/jeffbean/go-zookeeper
We'll certainly take a look. We've invested a fair amount in our reconfigure tools and dynamic client, but we never tried to upstream them. We did it as a small wrapper on top of this code as a connection manager.
On Wed, Dec 26, 2018 at 4:39 PM Jeffrey Bean [email protected] wrote:
I am actively going to be adding reconfigure APIs to this library in my own fork (dev branch). I intend on proposing a PR to this repo when its done but based on this thread and activity am not sure if it will be merged. is is possible to start an open org for something like this situation? I would be fine being a maintainer or reviewer of said org.
https://github.com/jeffbean/go-zookeeper
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/samuel/go-zookeeper/issues/165#issuecomment-450046830, or mute the thread https://github.com/notifications/unsubscribe-auth/AE19BCG3Rl3uxDjNPktxEId5uQ5Bt-WDks5u9BatgaJpZM4OWPGB .
We'll certainly take a look. We've invested a fair amount in our reconfigure tools and dynamic client, but we never tried to upstream them. We did it as a small wrapper on top of this code as a connection manager.
I have the PR up #205 . We also have a large investment and are looking to find the best path forward to contributing back. See https://github.com/gofrs/help-requests/issues/28#issuecomment-451030746 for more details.
Letting folks come back from end of year breaks to read and respond but we are looking to bring the community together.
cc @alxn
I have contributed a bit to this project as well and would be happy helping to maintain. I have some projects and some internal wrappers that are doing a lot of hacks as well.
Is @samuel still active? I have a new project soon and i'm in doubt between using this and the mesosphere one.
I have decided to take a bit of action here.
I have created the github org go-zookeeper (https://github.com/go-zookeeper) as a place where we can centralize some of these changes and provide a zookeeper client that isnt' tied to one github user.
If you are interested in help maintaining this for let me know and I can add you to the members (some invites already sent out).
The question is should we start the fork from samuel/zk and import the fixes from mesosphere or just start from a fork from mesosphere
CC: @jeffbean , @msolo, @gavv
I’m cool with this. I am in limbo on my side with logistics on a public fork so this is fine as well as I don’t see the end of the tunnel. I have some concerns with the mesos additions adding debug variables. If memory serves it itself have races in the tests. I can refresh myself on the specifics when I have some free time.
Generally I love this and support the move. Let’s work on just flat forking with no changes. Cut a semver and then move forward from there. That way folks can have a step one to change imports and change nothing.
I’m not a huge open source contributor but would a slack channel be something to streamline some of the forking coordination? I am in fact interested and have lots of surrounding libraries that can live in the github org as well.