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

When a responce from the developer/maintaner is expected #7

Open
guysoft opened this issue Sep 5, 2016 · 5 comments
Open

When a responce from the developer/maintaner is expected #7

guysoft opened this issue Sep 5, 2016 · 5 comments

Comments

@guysoft
Copy link

guysoft commented Sep 5, 2016

Its written several times in the readme, thought it might be a good idea to document its progress

@vdudouyt
Copy link
Owner

vdudouyt commented Sep 6, 2016

Sadly, I can't provide any estimates. I had even talked him by phone two years ago, but still no progress.

@guysoft
Copy link
Author

guysoft commented Sep 6, 2016

If its been 2 years ago then he is likely not going to do anything. Which means you could either ask him if the main project should move here, or declare an official fork.

@vdudouyt
Copy link
Owner

Is it possible to ask you to push him or mhddfs maintainers in mainline distros? I also believe that this changes should be adopted by upstream ASAP, but don't have enough time for doing politics.

The essence of this repo is in the following commits:

403e52f: nailed the first and most pesky segfault that I have found while running mhddfs in production
4cba41d: old versions of FUSE contain a bug that was also sometimes leading to segfault. That's why we need to ensure that we're building as least against the version 2.9.4
175e153: because mhddfs a regular executable, it's a subject for max open files limitation which is implied by OS. This was leading to really cryptic bugs when, for example, Nginx says that there are no more available file descriptors left - while the limit that was specified in nginx.conf wasn't reached. At this moment I have just put a default value which is good enough but, as you understand, it's better to also make this changeable through the CLI interface (while keeping this value which is good enough by default).

What I also have to say is that I'm using this one in production for two years, and there were no 'Transport endpoint not connected' issue since I have done all of these changes.

Best Regards,

Valentin

@guysoft
Copy link
Author

guysoft commented Sep 14, 2016

I spoke to a debian developer, what you can do at least for debian/ubuntu is to propose a "non-maintainer upload" or nmu. There are several guides to do that, initially you need to open a bug.

@guysoft
Copy link
Author

guysoft commented Sep 14, 2016

If you get stuck during the bug opening you can also ask @kaplanlior for advice

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

2 participants