Merge with the advban module

@anybody are you interested in co-maintaining ban? I volunteered to help get it out of core, but I'm looking for others to progress it in a 2.x branch.

As an advban developer, I am against merging modules.

@anybody I've opened #3575345: Seeking co-maintainers for next generation of Ban module, let's continue the co-maintainership discussion there.

Will leave this open for a while for a response to #4.

My maintainership of this module is primarily to help remove it from core, I'm afraid I don't have much meaningful input in to the future of this module beyond that. From what I understand, advban does not extend from ban, instead it seeks to replace it. It could make sense to simply recommend users switch to advban and stop supporting this module after a while. It would certainly be better to collaborate in one place (here or there) if possible. It would be good to understand from a site builder perspective, when should one choose one module over the other.

I think on a technical level, there isn't really such a thing as merging two modules. There's really only deprecating one in favor of the other.

So per #8, we either say that we mark this as unsupported in favor of advban and accept the name advanced ban as a historic thing and it's really just "the" ban module going forward.

Or we create a 2.x branch of ban and merge in all the features from advban either wholesale or on a case-by-case basis. We don't *need* support from the advban maintainer to do so as long as proper credit is given, but it's a bit awkward if there's no plan/commitment from the advban maintainer to recommend using the ban project/join as a maintainer, we'd then essentially maintain two more or less identical projects going forward.

We use the "Ban stack" of perimeter + ban + auto_unban. I clearly prefer that over the alternative autoban project that's built on advban, as it's real-time and stops scanners immediately as opposed to delayed on cron when they might have already sent hundreds of expensive requests. I also like how auto_unban treats repeat offenders by giving them increasingly long but temporary bans. As opposed to one-off expirying bans like advban implements it. We've had a handful of cases where real users managed to get blocked by perimeter and auto_unban typically resulted in them getting unblocked quicker than they managed to reach out to us. I also see that advban currently has the same performance issue that I patched in auto_unban: #3551605: Injecting ConfigFactory into BanIpManager is expensive, use a closure.

Looking at the advban code, the ability to block IP ranges comes at the price of executing at least one additional query to get that information as well. It doesn't seem optional right now. Not sure that's worth it for me. We rarely block IP ranges manually and mostly rely on perimeter. Our hosting provider (upsun) and CDN's we use (Fastly/Cloudflare/...) also offer IP range blocking that once active, is much more efficient.

So personally, I'm not sure I'd want to go in the direction of deprecating this project in favor of advban. If there are specific features that would be useful to support in ban, we could add them, either based on advban implementations or alternatives such as auto_unban. And keep them as different projects handling different use cases.

@berdir,
I mostly agree with your words.
You're absolutely right that one scenario is for one module to win and the other to die. But why should I shut down my module and throw away years of my efforts? This might be all I have.

My opinion is that users and module developers who use provider bans must make a choice. Like choosing between Mercedes and BMW.
Now I see that I am losing by a landslide, but the colors of my flag are different and therefore there are no options for me.

I haven't made any inventions or patented any of my improvements. Since the module is open source, you are free to analyze the code and use any useful ideas for your own projects. I can't stop you from doing so, even if I wanted to.

I have grand plans to create advban 2.0. But I'm not sure if I should make these ideas and solutions publicly available.
Now I regret creating those two modules of my own. And even registering on drupal.org.

Gentlemen, I apologize for not responding to you all. You are right in your own way, and I wish you continued growth and success in your projects.

@goodboy I don't think anyone is suggesting you abandon your work or your vision for 2.x, the invitation is here for you to collaborate and bring it to ban 2.x. It's up to you though, feel free to carry on.