Better indicate the quality of the project

I think it's fine to ignore this issue.

@chx,

Thanks for your opinion. I understand that creating similar modules is not a best practise on drupal.org. But I started MS development when I figured out that Memcache API is not maintained. There wasn't commited anything for a long time, even RTBC patches. I thought that Memcache API is missing for a lot of features and I didn't want to waste my time for patches that won't get commited. Moreover, to implement some features Memcache API needs deep refactoring. So it seemed to me absolutely impossible to do this at that moment.

Currently I don't really mind about abandoning this project, but only when all features will be implemented to the Memcache API. If I get a co-maintainer on Memcache API I'll be proud to do this and to take over all on 7.x and 8.x issues. If you don't want me to work on Memcache API I'd love to collaborate with anyone who is able to do this.

I am glad indeed that I was able to pay the community's attention at the problem with memcache integration. Hope that together we can succeed in this area and provide module that our community deserves.

@greggles,

Thanks, you helped me to accept @chx's opinion easier :)

@chx,

Sorry, but lapses wasn't Momentary. There was no progress for a year.

Talking about Memcache API maintainers - seriously, I have absolutely no doubts that all of them are really powerful and extremely cool developers. But time is passing by, and if they don't work on the project - it just won't grow.

I didn't say that the Memcache API project should be closed or abandoned. All I did is just created a solution that works for me and some other developers. I implemented all features that was in Memcache API, even from @todo list. I started to extend its features, bringing new wave in intergration with memcached. I provided better UI and new features for the site developers. I'm always quick and kind to support any issues for this project, while other developers don't. So where is the problem?

I admited my mistake in claims about Memcache API and removed that lines. Seriously, you can name people who never make a mistakes?

I could create this module and don't share with anyone. Instead of this I spend a lot of time in development, writing articles about this (sorry, but in Russian language), making progress in integration with memcached - and all you can tell me is that I should abandon my project because no need to create alternatives? Please, tell me how big expirience do you have in using Memcache API? I'm sure that you just don't see a difference between modules because you didn't use them as much as I did.

I can start implementing features into Memcache API. But till the moment when my patches will be applied, I still need a work solution for my projects.

> here is no (new) problem with the memcache integration

There IS a problem. Memcached allows users to do more than Memcache API allows. And I don't know any reason that doesn't let anyone to create a project with implementation of all its features.

My apologies if this message is got to be too emotional, I never want to offend anyone. I'm just worrying about this project.

@Spleshka I think it was a good idea to share your code and publish it on drupal.org given that at the time the Memcache API seemed unmaintained. Note that in these conditions it is recommended to follow the procedure for dealing with abandoned projects and thus avoid duplicate projects to emerge (which are confusing for users). I'm sure you were not aware of this possibility at the time. This would have allowed you to possibly be granted git write access to that repository where you could have started a new branch with the refactoring you wanted to see (which you did in a separate repo/project instead).

Nobody will fault you for that oversight, especially if you start contributing ideas and code to the older Memcache API project. Please file issues and contact the maintainer of the Memcache API project who might be willing to give you access to the repository so you can work on a new branch to refactor the module with your ideas.

@scor, I know about dealing with abandoned projects :) But the point is that Memcache API was not abandoned, was just temporary not maintained. See #1943866: Request to replace module.

I'll see how can I help Memcache API. But I'm not sure that @Jeremy accept my candidature as a co-maintainer :)

I see no reason to abandon the project because memcache maintainers won't implement new features #1943866: Request to replace module

Also better to have 2 different approaches (like redhat and fedora) to allow people choose what they really need.

we are about choice

PS: code base and api now very different and not compatible so I see no reason to provide upgrade path from old buggy module

Here are the 4 issues where Spleshka participated. As you can see, Jeremy and Spleshka have different ideas about how to do things. That's no reason to lambaste Spleshka.

re #3 - since when is the age or status of an account important in a do-ocratic/meritocratic project?

Fixing cross post. I agree with the status.

@andypost and @greggles,
Thanks for your support, much appreciate.

I agree, and after reading #1943866-23: Request to replace module and #1940554-2: Memcache module alternative, the maintainer of the Memcache API module is clearly not interested in any kind of refactoring, so I'm not surprised @Spleshka had to create a new project to share his refactoring. I wish I had seen these issues earlier, it would have helped to understand.

I'd recommend you to write/blog about your module and explain in what ways you think your refactored version of the module is better, while remaining objective. See if you can get some interest from the community in your module by providing good + objective arguments. Seems like @quicksketch for example wasn't opposed to see a refactored version of the memcache module. It's unfortunate your refactored version can't live in a git branch on the main memcache API namespace.

@Spleshka You have all my support, alternative modules oftenly bring good to the module ecosystem, and choice too.

@pounard, thanks! Nice to have your support :)

Updated issue summary.