[384.18_Alpha Builds] Testing all variants

[RMerlin]

Ax88U GPL (3.0.0.4.384.9107) released @RMerlin

Can't use it, the code is incompatible with the binary blobs used by the RT-AX56U and RT-AX58U.

 

[S.claus]

Can't use it, the code is incompatible with the binary blobs used by the RT-AX56U and RT-AX58U.

Possible compile for ax88u only ?

 

[dave14305]

Possible compile for ax88u only ?

Don’t tug on Superman’s cape.

 

[Deleted member 22229]

Don’t tug on Superman’s cape.

And never spit into the wind.

 

[RMerlin]

Possible compile for ax88u only ?

So you want me to spend two days merging and debugging a new GPL, and develop a FOURTH separate firmware, just for ONE model and only for until the other models get updated? Not gonna happen.

The situation is currently a complete mess, and a major headache for me. Here's how it's currently looking, as of today:

https://docs.google.com/spreadsheet...Xq4I0i6lQo-RN48SGFSkKNKq8/edit#gid=2007755387

And keep in mind that those released GPLs weren't all released at the same time. Some came out 2-3 days after the firmware release, others took 1-2 months.

Quite frankly, I can't keep going on like this. My current development workflow is unsustainable with Asus not having a predictable workflow (i.e. they do not update all models at the same time, and inter-model code compatibility will break all the time at some point). Some GPLs take 1-3 months to be available. And by the time they come out, the code available for other models is no longer compatible, meaning it's impossible to have one single release covering all models, unless I wait 2+ months to have everything compatible for all models at hands. Meaning my code would always be months behind Asus's.

So this is a big reason when whenever someone come in here and posts "Why is my model not available???" or "new GPL was released 20 minutes ago, when will it be merged???", it really, really pisses me off, and I have to fight not to be downright insulting in my response.

I need to figure out a way to adjust my development workflow, or this is going to end up in a wall.

And the addition of the last two models made everything even much worse. The AX branch (which already is separate from other models) has three models, and all three are getting separate, staggered firmware and GPL updates, making it completely impossible to keep all three of them in sync. The one thing for sure is, as of right now, I am not adding any new model at all unless I can find a way to make this work, or Asus's workflow changes to make things more predictable.

 

[brummygit]

View attachment 23805 Has anyone else mentioned the clocks in QOS don't have numbers anymore?

Firefox and Chrome

It's the same in the stock firmware - I presume to accommodate being able to set the scale they are displaying at

 

[jsbeddow]

So you want me to spend two days merging and debugging a new GPL, and develop a FOURTH separate firmware, just for ONE model and only for until the other models get updated? Not gonna happen.

The situation is currently a complete mess, and a major headache for me. Here's how it's currently looking, as of today:

https://docs.google.com/spreadsheet...Xq4I0i6lQo-RN48SGFSkKNKq8/edit#gid=2007755387

And keep in mind that those released GPLs weren't all released at the same time. Some came out 2-3 days after the firmware release, others took 1-2 months.

Quite frankly, I can't keep going on like this. My current development workflow is unsustainable with Asus not having a predictable workflow (i.e. they do not update all models at the same time, and inter-model code compatibility will break all the time at some point). Some GPLs take 1-3 months to be available. And by the time they come out, the code available for other models is no longer compatible, meaning it's impossible to have one single release covering all models, unless I wait 2+ months to have everything compatible for all models at hands. Meaning my code would always be months behind Asus's.

So this is a big reason when whenever someone come in here and posts "Why is my model not available???" or "new GPL was released 20 minutes ago, when will it be merged???", it really, really pisses me off, and I have to fight not to be downright insulting in my response.

I need to figure out a way to adjust my development workflow, or this is going to end up in a wall.

And the addition of the last two models made everything even much worse. The AX branch (which already is separate from other models) has three models, and all three are getting separate, staggered firmware and GPL updates, making it completely impossible to keep all three of them in sync. The one thing for sure is, as of right now, I am not adding any new model at all unless I can find a way to make this work, or Asus's workflow changes to make things more predictable.

I strongly suspect that there is a significant group of forum members that have been following this project for years now and are eternally grateful for your time, energy and commitment. "We" will never begrudge or whine about "when will this feature/fix/GPL be merged", as we are well aware of the inconsistent schedule that Asus follows. Don't let the handful of whiners (those who complain as soon as a new Asus firmware appears and ask when it will be merged), just know that most of us really appreciate your work. Thanks, and let us know if there is anything we can do to pressure Asus into a more reasonable schedule.

 

[skeal]

So you want me to spend two days merging and debugging a new GPL, and develop a FOURTH separate firmware, just for ONE model and only for until the other models get updated? Not gonna happen.

The situation is currently a complete mess, and a major headache for me. Here's how it's currently looking, as of today:

https://docs.google.com/spreadsheet...Xq4I0i6lQo-RN48SGFSkKNKq8/edit#gid=2007755387

And keep in mind that those released GPLs weren't all released at the same time. Some came out 2-3 days after the firmware release, others took 1-2 months.

Quite frankly, I can't keep going on like this. My current development workflow is unsustainable with Asus not having a predictable workflow (i.e. they do not update all models at the same time, and inter-model code compatibility will break all the time at some point). Some GPLs take 1-3 months to be available. And by the time they come out, the code available for other models is no longer compatible, meaning it's impossible to have one single release covering all models, unless I wait 2+ months to have everything compatible for all models at hands. Meaning my code would always be months behind Asus's.

So this is a big reason when whenever someone come in here and posts "Why is my model not available???" or "new GPL was released 20 minutes ago, when will it be merged???", it really, really pisses me off, and I have to fight not to be downright insulting in my response.

I need to figure out a way to adjust my development workflow, or this is going to end up in a wall.

And the addition of the last two models made everything even much worse. The AX branch (which already is separate from other models) has three models, and all three are getting separate, staggered firmware and GPL updates, making it completely impossible to keep all three of them in sync. The one thing for sure is, as of right now, I am not adding any new model at all unless I can find a way to make this work, or Asus's workflow changes to make things more predictable.

Personally I would prefer being late and on your firmware, than current and on thiers, in my humble opinion anyway.

 

[RMerlin]

Don't let the handful of whiners

Just to make sure it's clear: these are not the problem. The code availability situation is.

Thanks, and let us know if there is anything we can do to pressure Asus into a more reasonable schedule.

Asus isn't going to change their business-driven workflow just to accommodate one single third party developer. The current situation isn't because they are doing something wrong, it's just because the way they are working doesn't align with my own workflow (with a fixed development cycle, followed by a single release covering all models at once). This has caused me to extend my dev cycle from 1 month to 2 months, and now I would have to either extend it even further, or completely change my workflow. Such a revised workflow could be to do like them, and move into a more continuous development cycle, where I release a handful of models whenever these models are available regardless of which models can't be updated at that time. This carries however a few issues:

- Critical security updates would be a nightmare to handle, as not all models would be on the same codebase, being staggered all over my code history
- Currently a release requires roughly an entire evening of my time:
o Build and package all firmware images
o Upload to both download sites
o Update the manifest on the update server
o Update my website
o Write and publish release notes to SNBForums
o Announce the release to Twitter
o Monitor for any major breakage being reported in the first 1-2 hours


That release process would have to be somehow greatly simplified for it to be realistically doable more frequently than just every 1-2 months, as it's time consuming, and not something I'd be willing to repeat every few weeks.

 

[fearz]

We highly appreciate all your efforts man, nothing was meant to be offensive and your responses are totally kind and respected.

Keep it up..

So you want me to spend two days merging and debugging a new GPL, and develop a FOURTH separate firmware, just for ONE model and only for until the other models get updated? Not gonna happen.

The situation is currently a complete mess, and a major headache for me. Here's how it's currently looking, as of today:

https://docs.google.com/spreadsheet...Xq4I0i6lQo-RN48SGFSkKNKq8/edit#gid=2007755387

And keep in mind that those released GPLs weren't all released at the same time. Some came out 2-3 days after the firmware release, others took 1-2 months.

Quite frankly, I can't keep going on like this. My current development workflow is unsustainable with Asus not having a predictable workflow (i.e. they do not update all models at the same time, and inter-model code compatibility will break all the time at some point). Some GPLs take 1-3 months to be available. And by the time they come out, the code available for other models is no longer compatible, meaning it's impossible to have one single release covering all models, unless I wait 2+ months to have everything compatible for all models at hands. Meaning my code would always be months behind Asus's.

So this is a big reason when whenever someone come in here and posts "Why is my model not available???" or "new GPL was released 20 minutes ago, when will it be merged???", it really, really pisses me off, and I have to fight not to be downright insulting in my response.

I need to figure out a way to adjust my development workflow, or this is going to end up in a wall.

And the addition of the last two models made everything even much worse. The AX branch (which already is separate from other models) has three models, and all three are getting separate, staggered firmware and GPL updates, making it completely impossible to keep all three of them in sync. The one thing for sure is, as of right now, I am not adding any new model at all unless I can find a way to make this work, or Asus's workflow changes to make things more predictable.

Sent from my iPhone using Tapatalk Pro

 

[Deleted member 22229]

The Merlin meltdown. I knew it would happen. Thanks for sharing.

 

[DarkKnight75]

Merlin firmware is great...but i went back to stock cause Asus takes foreever to release open gpl code...btw the latest stock 81918 on my ac86u is running great.

 

[DAVID LONG]

I have learned in most aspects of life not to expect anything, especially if it is free.

Whenever something comes along I am grateful for what was given.

Thank you Merlin for all that you do.

 

[juched]

Just to make sure it's clear: these are not the problem. The code availability situation is.



Asus isn't going to change their business-driven workflow just to accommodate one single third party developer. The current situation isn't because they are doing something wrong, it's just because the way they are working doesn't align with my own workflow (with a fixed development cycle, followed by a single release covering all models at once). This has caused me to extend my dev cycle from 1 month to 2 months, and now I would have to either extend it even further, or completely change my workflow. Such a revised workflow could be to do like them, and move into a more continuous development cycle, where I release a handful of models whenever these models are available regardless of which models can't be updated at that time. This carries however a few issues:

- Critical security updates would be a nightmare to handle, as not all models would be on the same codebase, being staggered all over my code history
- Currently a release requires roughly an entire evening of my time:
o Build and package all firmware images
o Upload to both download sites
o Update the manifest on the update server
o Update my website
o Write and publish release notes to SNBForums
o Announce the release to Twitter
o Monitor for any major breakage being reported in the first 1-2 hours


That release process would have to be somehow greatly simplified for it to be realistically doable more frequently than just every 1-2 months, as it's time consuming, and not something I'd be willing to repeat every few weeks.

This is a tough problem. Things may settle as ASUS gets AX routers settled, or may just be the tip of the iceberg.

The GPL merge is the longest part? Do you get many conflicts on a typical merge which needs thought?

If it is conflicts with your feature set perhaps some consideration could be done to drop some.

The updating of the site and other items like that could be scripted.

Could people help you be doing pull requests for GPL merges? I know it is a trust issue, but curious.

 

[Mark Taylor]

only trouble is I rolled back to 384-17 rel and now cannot log in to router gives me wrong password or login name ,i've tried in4 browsers all the same . do i have to reset and start over ? or is there another easier way ?
thanks

I had a similar issue as I had the 384.18 Alpha on my AX88U but had constant internet disconnections. So I thought I would see what was in the latest Asus 9107 release and man I didn't realize how good and how many extra features were in Merlin's firmware ( big thanks again Merlin for all your efforts). So I then reset to factory defaults and reverted back to 384.17 and could not login. I realized and this i very unusual for a name field to be case sensitive but the username is in this case so I was using admin and in my backup restored it was Admin. So double check this as it had me stumped at first as the generic error is "Username or password is not correct" which is not that helpful in this instance.

 

[raven-au]

Just to make sure it's clear: these are not the problem. The code availability situation is.

Yeah, that one is an obvious problem, mainly due to ASUS development practices, which probably work fine for them but doesn't fit well for a single developer needing a consistent set of sources.

Asus isn't going to change their business-driven workflow just to accommodate one single third party developer. The current situation isn't because they are doing something wrong, it's just because the way they are working doesn't align with my own workflow (with a fixed development cycle, followed by a single release covering all models at once). This has caused me to extend my dev cycle from 1 month to 2 months, and now I would have to either extend it even further, or completely change my workflow. Such a revised workflow could be to do like them, and move into a more continuous development cycle, where I release a handful of models whenever these models are available regardless of which models can't be updated at that time. This carries however a few issues:

TBH I think you don't really have much choice but to align with the ASUS development practices.
That will no doubt lead to a possibly painful transition but what's more important is formulating how you could do that in a way that satisfies what you need to get out of the project so that your happy with the result and are motivated to continue with it.

That's no easy task to be sure.

There are a few things that come to mind.
- versioning, probably needs to change to accommodate some sort of division of development kit needed for various models.
- divide and conquer, find a way to enlist the help of others, possibly via git pull requests, possibly not since that could lead to even more work reviewing and co-coordinating merges. OTOH it could be an opportunity to improve project management skills, it isn't easy to manage a desperate group of volunteers with varying skills.
- multiple repositories based more on development kit model groups. Probably not something you much like but is, I think, more aligned to how ASUS does this.
- they probably have a source tree for every model and back port, or forward port between them when working on each.
- having a tree for every model or group of models would mean more work overall but it should allow less overhead for any given model (group) release.

Now I'm sure there's more I should be saying but can't think of it now.
And I expect you won't be too enthusiastic on such large changes given there's a good reason to do it the way you do now, simplicity (once upon a time anyway).

But I thought posting some ideas was worth while since you say things need to change.
So please take it how it's meant, thoughts and suggestions to foster further discussion,

- Critical security updates would be a nightmare to handle, as not all models would be on the same codebase, being staggered all over my code history
- Currently a release requires roughly an entire evening of my time:
o Build and package all firmware images
o Upload to both download sites
o Update the manifest on the update server
o Update my website
o Write and publish release notes to SNBForums
o Announce the release to Twitter
o Monitor for any major breakage being reported in the first 1-2 hours


That release process would have to be somehow greatly simplified for it to be realistically doable more frequently than just every 1-2 months, as it's time consuming, and not something I'd be willing to repeat every few weeks.

Perhaps, since the number of models is growing and the number of development kits in use is growing too simplicity isn't possible.
Possibly release cycles need to be extended and divided into groups so that the amount of time for each is reduced (at least a little).

If the division is done well (and I don't know even what that means) that should limit the "but this model has that and mine doesn't when will it happen" type problem, the response being "that's a different version of the router development kit, it'll be done when it's done if it's included in that kit at all".

It could also lead to a natural obsolescence process where models transition into a bug fix only, best effort only mode but are still (I say loosely) supported so the overhead becomes less for those models. Yes I know that's kind off already done but formalizing that process could clarify that process and reduce overhead of the number of fully supported models vs. limited support models, after all there are just too many models for one person to realistically deal with, particularly those that are on limited support by ASUS themselves and this would fit well with that aspect of the ASUS development model too.

But, yes, this would mean more work overall a more complex repo., and a need for a clear definition of the divisions up front, perhaps with branches, or multiple repos, or both and consistent release tagging within branches also clearly defined up front too. But it also might lead to a higher participation form other that can help, or perhaps not, don't know.

Ok, so thought I was finished above but wasn't, same sentiment applies here too.
I really hope you can find a suitable way to go forward that satisfies what you want to get out of the project without resulting in too much increased direct overhead.

Ian

 

[RMerlin]

The GPL merge is the longest part? Do you get many conflicts on a typical merge which needs thought?

Yes. A lot of merges have to be done manually instead of diff/patch, either due to merge rejects, or improperly applied patches (very frequent for instance with the firewall code, due to the large amount of duplicate code in it, which confuses diff/patch).

And if Asus takes a long time between GPL updates, then there will be so many changes that it can take me a whole week just to merge, clean up, resolve incompatibilities, and so on.

If it is conflicts with your feature set perhaps some consideration could be done to drop some.

This is why for the past two years I refused the vast majority of new feature requests people made.

The updating of the site and other items like that could be scripted.

Already largely scripted. Building, packaging, uploading to Onedrive/SF.net, and publishing changelog and SHA256 hashes is scripted. Everything else has to be done manually.

Could people help you be doing pull requests for GPL merges?

No. GPL merges are so complex, I'm probably the only person in the world who is currently able to handle these, since I have 8 years of experience in dealing with them, plus I'm the only one familiar with all the changes I have done over the years, so I can tell at diff time which parts of my own code will require to be separately changed afterward. For example, the certificate handling changes Asus did in their recent releases, which required me to review my own related code. I had to set aside an evening to review and update these portions of the code.

 

[fearz]

Well then the best we can do is to donate for your tremendous support Eric.

I don’t want to deviate the topic of the thread, but to support go to the Merin firmware/project website:

https://www.asuswrt-merlin.net/

You’ll find the paypal donation button...

Just donated, and if you need any testings or support whatsoever, we’re here to help.

God bless.

Yes. A lot of merges have to be done manually instead of diff/patch, either due to merge rejects, or improperly applied patches (very frequent for instance with the firewall code, due to the large amount of duplicate code in it, which confuses diff/patch).

And if Asus takes a long time between GPL updates, then there will be so many changes that it can take me a whole week just to merge, clean up, resolve incompatibilities, and so on.



This is why for the past two years I refused the vast majority of new feature requests people made.



Already largely scripted. Building, packaging, uploading to Onedrive/SF.net, and publishing changelog and SHA256 hashes is scripted. Everything else has to be done manually.



No. GPL merges are so complex, I'm probably the only person in the world who is currently able to handle these, since I have 8 years of experience in dealing with them, plus I'm the only one familiar with all the changes I have done over the years, so I can tell at diff time which parts of my own code will require to be separately changed afterward. For example, the certificate handling changes Asus did in their recent releases, which required me to review my own related code. I had to set aside an evening to review and update these portions of the code.

Sent from my iPhone using Tapatalk Pro

 

[RMerlin]

divide and conquer, find a way to enlist the help of others, possibly via git pull requests,

Over the years I have asked for people willing to take over maintaining older models like the abandoned models, or the AC87/AC3200 models currently parked on a separate code branch. No one stepped forward.

- multiple repositories based more on development kit model groups. Probably not something you much like but is, I think, more aligned to how ASUS does this.

This is basically what I had to do as I had to split development into mainline, ax, and recently 384.13_x branches. I can't see myself doing that for 10+ separate models, and handling all of these on my own.

they probably have a source tree for every model

They don't. They do have multiple branches, however they simply release models off these branches as they are ready. For instance, the RT-AC88U/AC3100/AC5300 are all from the same branch, but they don't release updates them at the same time, hence the different versions as seen in my published spreadsheet.

And I suspect my current separate branches are very similar to their own: 382 (which is currently my 384.13_x branch in terms of models), 384 "main", and 384 "ax". They also appear to have a 385 branch for some models, but from what I've seen the code is identical to 384, just with a different version numbering. And they have the 386 branch, which is their most up-to-date, but so far only used for very few models, like the Zenfi. The DSL-AC68U was the first existing model that I have seen getting moved to it.

Which will eventually be a new headache of its own. I had to go through that in the 380 -> 382 switch, and it was painful. To the point that, at the time, I decided to scrap my code, get a fresh GPL code, and re-implement all of my changes on top of that new GPL.

 

[Vexira]

I have this strange feeling that Asus is in the process of transitioning form AC units to Ax ones, and they are slowly phasing out the AC devices, this is just my theory in regards to firmware release cycle.

Which would mean that less gold would be available for non Ax units.