ZudVPN VS bors-ng

I am creating an open source VPN application for mobile phones (iOS, Android) and a chrome extension as a proxy. I wonder what features people expect from a VPN.

My MVP is that the app will functions as a VPN launcher on user's preferred Cloud Provider like Amazon Web Services, Google Cloud Platform, Microsoft Azure, DigitalOcean, Vultr and any other major cloud provider that offers API access.

Features, I envision to add are: Ad-blocking by DNS, VPN Kill Switch, Static IP (if provider has it), IKEv2 IPSec-based VPN solution like strongSwan, and since the server belongs to the user, I plan to add a Terminal right in the app so that the user could connect and do anything they want.

Since the app is an open-source I pushed initial PR to GitHub so that anyone can scrutinize the code: https://github.com/zudvpn/zudvpn

- In your components, just call `useStore` hook and require whatever state property you need: https://github.com/zudvpn/ZudVPN/blob/master/src/screens/MainScreen/index.tsx#L13

GitHub: https://github.com/zudvpn/ZudVPN

When I first started on react native I used react-native-navigation and never looked back. I don't have any experience with react-navigation. So far I can't complain about react-native-navigation on https://github.com/zudvpn/ZudVPN

When using random VPN are you sure the risk is not owned by you? Here is the cloud config init data that is used to create the server: https://github.com/zudvpn/ZudVPN/blob/master/src/providers/DigitalOcean/cloudconfig.tsx Feel free to see if it's worth the risk or not.

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.