This really bothers me.

This should not be added in any 6.x releases. This is not a "small" new feature as it probably required serious changes to the firewall coding. Stuff like this needs to be fully tested before hitting the actual release chain. The 6.28 release broke a LOT of stuff, and now 6.29 is supposed to fix everything AND add this major change in?

You guys need to separate properly between fixing/stabilizing the firmware, and THEN adding new stuff. Don't do both steps at the same time.

This isn't/wasn't a requested feature either. Where did people ask for this? There are dozens upon dozens of feature requests that are active. Why not address those first? This is an "ok" tool, but we can live without it compared to some other feature requests that I would say are much more needed (And some of which are much smaller to build than this).

MT guys, you were getting much better at your development releases, and now you are starting to slip again. Stop.

You guys need to separate properly between fixing/stabilizing the firmware, and THEN adding new stuff. Don't do both steps at the same time.

+100

This really bothers me.

This should not be added in any 6.x releases. This is not a "small" new feature as it probably required serious changes to the firewall coding. Stuff like this needs to be fully tested before hitting the actual release chain. The 6.28 release broke a LOT of stuff, and now 6.29 is supposed to fix everything AND add this major change in?

You guys need to separate properly between fixing/stabilizing the firmware, and THEN adding new stuff. Don't do both steps at the same time.

This isn't/wasn't a requested feature either. Where did people ask for this? There are dozens upon dozens of feature requests that are active. Why not address those first? This is an "ok" tool, but we can live without it compared to some other feature requests that I would say are much more needed (And some of which are much smaller to build than this).

MT guys, you were getting much better at your development releases, and now you are starting to slip again. Stop.

+1! This is EXACTLY what I though when I saw the last changelog.

May I add that, with so many ongoing (and possibly new) stability problems with v6, I was really puzzled to hear the MT claim made during a recent MUM, that v7 will be out this year. Do you really have the necessary development resources to do development of two major versions concurrently, while at the same time, you keep adding features (thus introducing new bugs) to BOTH of them?

I certainly hope that you are not planning to leave v6 in a semi-stable state, to focus solely on an premature and notoriously unstable v7, when it comes out.

This really bothers me.

This should not be added in any 6.x releases. This is not a "small" new feature as it probably required serious changes to the firewall coding. Stuff like this needs to be fully tested before hitting the actual release chain. The 6.28 release broke a LOT of stuff, and now 6.29 is supposed to fix everything AND add this major change in?

You guys need to separate properly between fixing/stabilizing the firmware, and THEN adding new stuff. Don't do both steps at the same time.

This isn't/wasn't a requested feature either. Where did people ask for this? There are dozens upon dozens of feature requests that are active. Why not address those first? This is an "ok" tool, but we can live without it compared to some other feature requests that I would say are much more needed (And some of which are much smaller to build than this).

MT guys, you were getting much better at your development releases, and now you are starting to slip again. Stop.

Most of the major network vendors do the same thing, they just note the release as maintenance (fixing bugs - no new features) or general (fixing bugs and adding new features). It would be nice to see MikroTik adopt a similar convention when announcing releases or even put a freeze on new features every couple of releases to focus on stability.

When you're dealing with a product that is designed to be so economical, there has to be some give/take in the development process due to resource limitations at MT. In many respects, we (users) are our own worst enemy because we are constantly begging for new features and then rant and rave when those new features break things.

I for one am glad to see performance increases like this because I believe they are probably building blocks in the plan to unlock the full potential of the CCR/CRS/2011/3011 architecture.

Complication of development has its price. Directly and in dollars
And this is leading to market positioning. I think things are not so simple..

This really bothers me.

This should not be added in any 6.x releases. This is not a "small" new feature as it probably required serious changes to the firewall coding. Stuff like this needs to be fully tested before hitting the actual release chain. The 6.28 release broke a LOT of stuff, and now 6.29 is supposed to fix everything AND add this major change in?

You guys need to separate properly between fixing/stabilizing the firmware, and THEN adding new stuff. Don't do both steps at the same time.

This isn't/wasn't a requested feature either. Where did people ask for this? There are dozens upon dozens of feature requests that are active. Why not address those first? This is an "ok" tool, but we can live without it compared to some other feature requests that I would say are much more needed (And some of which are much smaller to build than this).

MT guys, you were getting much better at your development releases, and now you are starting to slip again. Stop.

we (users) are our own worst enemy because we are constantly begging for new features and then rant and rave when those new features break things.

While it's true that people want new things, and I do agree that we rant and rave when those things break stuff...

1) Mikrotik needs to start freezing firmware, and flat out say "Too Bad!" to new features at some point. There's no point in chasing new features while leaving a trail of destruction behind you. I'd rather have a stable router with limited functionality, then a Swiss Army Knife that can do everything but break every time I try and use it, or something I'm afraid will explode every time I make a config change. This would be an acceptable process if MT had a proper open workflow system for dealing with bugs (A forum isn't it!), and could deal with them in an open and timely manner.

2) Mikrotik should actually add in requests that are requested. Fasttrack was not requested anywhere. Yes it does help performance (Many are complaining about that, especially given the inflated numbers that the CCR does not live up to) but it still doesn't address the core problems behind performance in the first place. It's a band-aid.

You don't get this with major vendors. You get bugs, don't get me wrong there. But the stuff is usually tested better, and there are proper support/workflows in place that make it slightly less painful when something does happen. Most major vendors (That I'm aware of anyway) separate the firmware chains between new additions and stability fixes. We don't even have a proper beta chain here. The "Stable" is the beta. There should be a closed beta group for testing firmware before it gets released first. (7 does not qualify. 6.x needs this... If it goes live on the website, it needs to pass through a test user group first. Ubnt even does this, so it's not like it's financially restrictive, or a byproduct of being a "small, low cost" company or product.)

This really bothers me.

This should not be added in any 6.x releases. This is not a "small" new feature as it probably required serious changes to the firewall coding. Stuff like this needs to be fully tested before hitting the actual release chain. The 6.28 release broke a LOT of stuff, and now 6.29 is supposed to fix everything AND add this major change in?

You guys need to separate properly between fixing/stabilizing the firmware, and THEN adding new stuff. Don't do both steps at the same time.

This isn't/wasn't a requested feature either. Where did people ask for this? There are dozens upon dozens of feature requests that are active. Why not address those first? This is an "ok" tool, but we can live without it compared to some other feature requests that I would say are much more needed (And some of which are much smaller to build than this).

MT guys, you were getting much better at your development releases, and now you are starting to slip again. Stop.

+10000000 - fix problems first and solve regressions issues then add features requested!

If MT had the resources, it would be best to introduce a three-lane development model.

A "stable" version, which would be feature-frozen and mature and receive only security and bug fixes; then a "development" version where some new features would be widely tested (something like a beta) and lastly, a "bleeding edge" version for the bravest among us, for experimentation on the freshest and most immature stuff that may even break on eye contact (like an alpha/nightly). It would be up to each user to decide which train to ride on.

Much like the best reputed, enterprise Linux distros out there (Fedora --> Redhat springs to mind) or the dev trains of Chrome and Firefox browsers...

You don't get this with major vendors. You get bugs, don't get me wrong there. But the stuff is usually tested better, and there are proper support/workflows in place that make it slightly less painful when something does happen. Most major vendors (That I'm aware of anyway) separate the firmware chains between new additions and stability fixes. We don't even have a proper beta chain here. The "Stable" is the beta. There should be a closed beta group for testing firmware before it gets released first. (7 does not qualify. 6.x needs this... If it goes live on the website, it needs to pass through a test user group first. Ubnt even does this, so it's not like it's financially restrictive, or a byproduct of being a "small, low cost" company or product.)

You make some great points about the way code development is organized/managed and I agree we need a better bug tracking system that is public facing.

I do want to point out that major vendors like Cisco still suffer from the same kinds of issues. We work heavily in Data Center and Service Provider with Cisco gear as well as MT and I have fought more bugs due to regression and just bad QA in the Cisco Nexus line this last year than I ever have in MT.

Considering most Nexus deployments cost north of 1 Million USD, you would think the code development and testing would be better - unfortunately it isn't. I have been involved in almost a dozen catastrophic data center failures due to Cisco Nexus code issues in the last 12 months. Some of them were bugs that were fixed in previous releases.

There is definitely room for improvement, but this is an issue we struggle with across all network equipment vendors.