Nullvoid3771
commented
2 months ago “ I cannot support every single model on my own. Gnuton has been supporting multiple models for many years by now. If you don't like that, then sorry - that's just the way it is. I have a finite amount of time I can devote to this project. “ ~ Rmerlin
“ Gnuton is already forked from my code. While I do the primary code merge + development, he gets his model-specific GPLs from Asus, and handles the merge of these model's binary blobs himself. He handles development and distribution for his models, as the point there is for me not to have to devote any of my own time to these models.” ~ Rmerlin
In other word gnuton still has to build every specific gnuton build himself from Asus’s GPL. Where Rmerlin comes in is front end stuff that’s Merlin related maybe some patches for specific upstream entware that’s built into each build eg. busybox. Where bugs come into play for gnuton is he has to handle each routers build and development. If something doesn’t get merged into the build eg. cake-QoS that’s specifically added into Merlin then it just won’t work. It’s a lot to deal with I imagine, and well I’m sure he and Rmerlin have discussions they aren’t the same person so well I’m sure he does his best to review changes in the master branch code from Rmerlin; each specific model and each new model added is a new learning curve.
This is just my take. If gnuton would like to chime in on anything I said that’s fine. Appreciate the support he gives.
gnuton
ajay-gh
This is not really a specific, new bug (report), rather a question concerning "issues" already reported.
I understood that the purpose of this projects is to add more Asus routers to the list of supported routers (example the RT-AX58U v2) - without interfering with the functionality and integrity of Merlin releases. I assumed that you took the original Merlin firmware code (e.g. 3004_388.7_0) and made minor changes in a limited number of places in order to achieve this goal. In other words, I assumed that the bulk of the code remains working and stable. No need to continuously perform additional testing (not the dev, not the user) for each release or update. If that assumption was correct, how come a feature like the VPN client's kill switch (issue 595) - which works fine in the Merlin firmware for a long time - does no longer work and needs to be reported and eventually fixed ?
Hope you don't mind explaining. Such an explanation helps building trust when using a "custom version" (more or less unknown) of a "brand name" like Merlin. Please do not misunderstand, this is not a complaint. Your work is valuable and appreciated, but in some cases trust is vital and all a user can have.