tunnel VS bors-ng

We have updated our manual on github to make it more convenient for you to use VPNHouse. Follow the link to find out how to update service! After doing all the steps described in the manual, your VPN will become safer, more stable and more functional. You can read about updates and fixes in our releases. Don't forget to give a star to our project if you really like it!

VPN house announces an open-source VPN solution with the AGPL 3.0 license that you can set up on your devices. We made a perfect solution that avoids risks of banned VPN services. Deploy VPN node on your own platform and use it for free - it is an open-source.

You can easily run it with a pre-build Docker image or build it yourself. The solution is based on the modern and reliable WireGuard protocol.

An extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPsec, while avoiding the massive headache. It intends to be considerably more quickly than OpenVPN.

You are fully in control. Check the source code, build it yourself, choose where to deploy and what to do with your personal VPN server.

“Do you trust your VPN provider? Do you want to pay even more for high risks of gathering your personal data? Better buy your own VPS and set up your own VPN under your full control.” Sergey, senior developer, VPNhouse team.

You can start using our service in 4 steps:

1. Get your own virtual server (it makes your work on the internet safer)

2. Get the Docker container

3. Configuring it using an admin panel

4. Use your own VPN connection

We created two guides on how to set VPNhouse. First one suits you if you are a developer and don’t need screenshots and hacks, https://github.com/vpnhouse/tunnel#vpn-house. The second one is mostly for those who want to see step-by-step hacks and screenshots https://vanline.notion.site/VPNhouse-how-to-install-your-own...

You can further protect main branch by using a rollup approach (see Bors for an example) where the pre-merge tests are run against the combination of those PRs currently proposed for merging, which limits the possibility that two PRs look OK but together break something.

Completely independent implementations of the same underlying concept, one of which was written pretty much just for the rust project, and the other was written as a more general tool and service.

Merge commit (via bors) because I hate squash merges.

Maybe the author does not know that there's https://bors.tech which is a publicly available Bors instance. There's absolutely no operational cost involved except for the initial setup.

Or images. On pages like https://bors.tech and https://foodpartners.us the "bloat" is all images. The images are bigger than they were in the 1990's because they look better, even if you don't think they communicate more "information" people may still want them.

According to the README, it bisects. It doesn't matter much for me, though - the batches in our case were never big.

https://github.com/bors-ng/bors-ng/blob/master/README.md#how...

Sounds like they settled on the bors model of a batching merge queue. Gitlab's merge trains instead speculatively run all of the merges at once which gives more precise data at a higher cost and longer time, if your number of parallel runners is limited.