Id like to suggest something that might cause allot of ruckus.


One of the biggest problems i experience with MT is that it is released in a add-hock fashion.

Slapped together with what appears to be NO testing.

Now im not ragging a brilliant product, id simply like to suggest a better way of releasing it.

Via branches. A stable branch , A Developers Branch, A Release Branch.

or similar......

The stable branch is guaranteed to work with NO bugs or if there are few small ones, WELL documented!
A Release Branch, somewhat tested and suggested to become stable.
And the Developers branch, entirely untested , at you're own risk......


This is what will separate MT from say the cisco's.
If a company is structured correctly these issues will result in a analysis of the risk factors introduced by MT.

Way to often The software gets released and the bugs are so critical it brings down a network or causes unexpected greaf.

Another issue id like to bring up is the changelog!

What is the use of using it if it isn't complete? Often MANY bugs are fixed and not reported in changelog.
How does one know if one should upgrade to fix an issue if he must do it blindly at the HUGE risk of introducing new ones?


I do not consider the current methods professional and would simply like some input on this.

This is NOT meant to start a flame, and IF there are reasons, id like to know.

Thanks.

I second this request. My company is managing quite a lot of routerboard CPE's, and as it works now, we have no choice than to upgrade every time a new version has been released. which is a very tiresome process to facilitate with all our customers.

Eising, if all works fine and you are satisfied, then you should not upgrade =)

That i can agree with , but here is the problem....

I haven't found a version yet that hasn't got some bug that effects us.


And that's a bold statement!

Eising, if all works fine and you are satisfied, then you should not upgrade =)

And when you have a problem and ask for support? The first responce is upgrade to the latest version, which, ironically just introduces more bugs and problems.

do you think that it's easier for developers to support a few branches instead of one branch? =)

No, im sure it isn't however it is "in my opinion" is what will be the turning point for MT to be introduced in larger enterprises.

The aim was to make it easy and functional, and that they have to a level i never thought possible.


However if you look at the areas MT is used, its normally used in small organizations or ones that don't have specialized IT staff.
(I do say normally because , there are many large organizations that simply work with the risks , because of the feature set given)
In fact here in SA even our farmers with NO IT background are able to use it!!!!

Now this is great, however when it comes to the larger more professional organizations that investigate ANY solution before deploying.....
There comes the snags...

The Risk of using MT is actually very high as many procedures are not followed and this increases Risks.
I can list features missing or working incorrectly, procedures not followed etc....

But , yes , it would maby mean more staff, more effort, but the demands are there and for something this flexible there is a VERY bright future!!!


Input?

Id like to appeal to users to voice there opinion over hear, what are you're experiences?

i would also want to second this.
i'm a big supported of MT.
i just love it.
in our company i completly kicked out all cisco's in favor of MT based routers.
but every update is done, with a extended testing enviroment, with identical setups, just to make sure it's going to work.
BGP and OSPF are still fleaky and every update it becomes better.
But all this upgrading is really a job of it's own.

i'll like to see it just like linux kernel versioning... 2.5 dev 2.6 stable... ad so on...

in my oppinion he biggist problem with the MT guys is just that they are so good.
they try to make every feature work, and new features are introduced constantly.
but i prefer, major releases with features added, and then only fixes...
until another major release...
this way if you don't need a feature, and it works jou don't upgrade.

pls MT guys, prefer stability over features, you guys already have so much in your product.
make it stable then extend.

I've been on MT gear for a few years now, and although it's a great product I have refrained from using it for anything more critical than a minor distribution segment. I'm also using it for less wireless than most other people here, usually my MT gear is deployed in my data centers to achieve specialized results where normal Cisco gear is too expensive or lacks flexibility. I dare not run MT gear on any major network segment.

I enjoy sleeping at night even though data center life is something you can never really get away from, but I have various types of Cisco gear from 2950's to 3560's to 6500's w/Sup720's, and most of them have uptime's between 1-2 years. On my MT gear I'd be happy to make it 100 days without any weird stuff happening, and I have made a 100 day uptime on a x86 system. Then on the other hand I upgraded a RB532 from 3.14 to 3.15, and then it randomly freezes and reboots, it's only running a very basic hotspot config...supports answer "reload it using netinstall", now I do own a WISP company as well, and I don't have many devices in service, but I can already see the headache of having to go on site and reload a board or replace it all together with a fresh device.

With that same RB532 running the "stable" 3.14, I turned on OSPF two days ago, and set it up to pull a few subnets from an x86 MT device...the RB532 has crashed twice and rebooted itself in those two days. So great, I stay on 3.14 and OSPF seems to crash it, and if I upgrade to 3.15, it crashes for whatever other reason. If RouterOS isn't fully stable on their own hardware then, why in my right mind would I put a RouterOS device into a serious production network?

The biggest data center we have in service has 12Gbits of bandwidth connected to it, and I would love to run parts of the network off MT gear because of the wide range of features in a single device, but I can't afford to place a risk on something when support's answer is "try the new version" or "reload the os". I realize I can get a Cisco tech on the phone in minutes and MT is not Cisco, but at the very least MT support could take a look at the device (if reachable) and maybe find the problem.

Please keep in mind that this is not a negative reflection on MT, and I will continue to buy RB's and new x86 licenses, and I'd even be willing to pay more for the higher-end licenses. It's just that being a provider of networking gear I would expect better research and development in bug fixes. I'd be happier with less new features as long as it meant better stability.

This is a perfect example of the point i was trying to make!


For those people who need/want the new features that haven't matured yet, they can accept the risk and use the "development" version.

That way it cannot reflect on MT as it's clearly stated as "untested".


And i think the Guy's at MT can see here that NONE of us are bashing MT, only exploring it's flaws to make it a greater more reliable product.

FULL ACK

i absolutely see the "challenge" for mt-devs to always pack more technologies and possibilities in their software, because thats what makes it so flexible and made them as big and well known as they are.
but as they probably know since the first 3.x-versions this is a road to nowhere, as the product itself always gets more worse than the version before.
i read a few times that they do not want to be compared to cisco or juniper. that is acceptable if you target your product to a soho-market. but most of the customers imho are wisps or normal isps, and this market is in the hand of the big C and the big J (and maybe foundry and hp ). so you have to get yourself compared with your competitors, and i think, mt knows that these are their competitors, otherwise they wouldn't implement things like mpls, this is nothing for the soho-market but this statement always shuts off any criticism by comparing them to c and j.

of course there are many people who stick to ros 2.9 as probably many people stick to ios 12.2, just because its stable, does everything they want and they have no bugs to fight with. but cisco actually supports 12.2, mt just supports their latest versions. but it shows that a release policy just like the big ones do it is maybe the right way for mt.
i would appreciate it in a big way, it would make my network way less heterogen than it is right now. a good example is p-t-p-links in etsi-region. if there would be a stable release-process things like dfs2 or atpc could be implemented in a much nicer way, as it would not affect stable versions because it can be tested in a dev-version. as for now whe use ubnt ps5 or lancoms for high-power-links, as they have all required technologies like atpc and dfs2 on board.

so please, please, please change your release policies, it would open a market for customers, who really know what they are doing and would generate way less support-cases with stupid questions, because the audience is simply another one. but you would also care for the soho-market, as most of those customers (again imho) only use a small set of functions that work since a long time.

another solution is to break ROS to mush more packages and develop them like 'routing' package today, for example: there are 'routing' and 'routing-test' packages, the '-test' being actively developed and having all recent features =)

FULL ACK
It would be great.

I'm pretty cautious too. I have 74 MTs that I know of, and some are a couple hours travel, or intermittent access by $200 boat or plane trips depending on weather. I avoid at all cost putting a MT on a tower where it might be difficult or expensive to get a climber. I'll put in hundreds of dollars of LMR600 to avoid putting an MT on a tower where staff might have difficulty accessing it.

I do a little with MT wireless, but not that much, as some of the card choices have been unreliable, and the 532 was not fcc approved, but the 333/433 series are now.

I sit on the new software releases for a few days, I then install some on easy to get to local routers that aren't terribly important. Then a week or two or a month later if things are going well and there are no terrible issues that arise, I install the software in more places. Super important high volume routers I only update 3-4 times a year.

I would say routerOS has improved greatly via trial by fire, but I'm not able to take part in the field testing of poorly factory tested releases. I think they need some sort of automated test system that they don't have to try all sorts of configurations and applications. It might take a couple days for a automated test setup to run a MT through it's paces with the new release but it would help them cover their bases.

MT is a big step above Ubiquity as far as OS quality, but a big step below trustworthy brands many ISPs use like Cisco, HP Procurve, Novell, Redhat, etc...

Looks like this Thread might have help guys!
Have a Look at the download section on the Mikrotik Site!!!

More input would be greatly appreciated.

It looks to me as typical "glass half-full, or half-empty" discussion.

If you compare MT to plain Linux - MT is much,much,much better in every way and I do not want to change anything.

.......ok


Looks like 3.17 classified as stable! :/

Now that defeats point, and in fact isnt.

I think we should lock this topic, because the eternal question "what is stable" can't be answered. Use whatever version works for you, "previous stable" if you wish.