Questions I would like to see Joe respond to:

[Nick]

we will continue to drive new feature development while maintaining high quality.

When did you start? To my knowledge, this latest release that you are calling "gold" has gone backwards in development, considering the loss of features (e.g., profile customization) and consists of innumerable bugs and quirks that have existed since beta stages and perhaps as early as alpha stages. I see absolutely no quality in that.

You guys are releasing awfully quickly, which is awesome; but not when it's at the expense of product quality. You might be interested in checking out this post of mine: http://www.vbulletin.com/forum/showt...=1#post1881157

Next time, try not publicly setting a release date that you promise yourself to abide by. Release the product when it is ready. I understand you have stockholders to please, and although the cash-grabbing schemes you guys have pulled the past few months are bringing in some quick cash for you all, you'll notice the negative effects in the long run when nobody even considers your product. The vBulletin product and its name are being run into the ground to nothing more than dirt.

[smiggy]

I guess I worded it wrong.

When can we expect the maintenance releases for 3.8 rolling out again. I believe the next in line is 3.8.5.

Roy Morgan told me via PM shortly after the vB 4.0 goes gold.

[RadioErewan]

In terms of functionality CMS is goldstoper. We have

1. high query count
2. splitting comments (underthinked and reinvented)
3. bad FURLs for content with characters other than (abcdefgijklmnopqrstuvwxyz)
4. encode all other characters in FURLs idea - latin alphabet languages should have option to simplify it via conversion table in contrast to something other for asian multibyte characters.
5. weird section/article editing engine - mess with publication date
6. weird method of image scaling/aligning
7. lack of widgets installer (you have to apply code by hand like in stone age)
8. unthinked/forgotten ability to run different parts of suite in different folders/subdomains
9. last but not least - no unicode/utf support

Named most important problems, some of them are suitewide, some are cms specific. All should be addressed before Gold. All have been reported and discused here for last two months. Recurrently - every beta release. With no any feedback from architects/developers (or minimal in case of split comments).
Every problem from this list stops some of us - vB users - with CMS implementation. If every one deducts 10% from happy customers, we have only 10% of user base happy with current Gold.
One month of debuging and development could fix 70% of issues. Making vB4 + CMS more acceptable.
My question is: When could we expect any detailed explanation, which way vB4 "gold" fixing will go? When will we expect solution for points 1,2...9. Could you set up precise date for it, as it was with "gold"? Could some developers explain what is vBS position in problematic areas. Where are you going? Misty "having overwhelming value" is not as precise as e.g. 21st Jan. 2010. We all have invested in the future of vB4. Ray Morgan asked us to do so. It was $130 investment from my wallet. After "gold" it is clear it was not short term investment. Would like to know is it medium term investment (vB4 will be gold ready in lets say 3 months) or long term investment (vB4 will be gold ready when vB5 will be on horizon)?
"we can absolutely do better on CMS performance and we will be working on improving this in the future." is not precise too. When do you expect it to happen (dd-mm-yyyy)?

Regards

[Super Jinni]

1. A lot of folks have mentioned the high query count on CMS; I think 'query count' is a misleading metric. The real question is: how long does it take to render the page? We've made a number of fundamental changes to the DB schema in 4.0 that improve performance in a variety of areas, and some of the improvements have changed the way we approach some parts of the application design. In the case of CMS we would rather have a lot of tiny queries that take a few milliseconds each than a few large joins that take hundreds of milliseconds. Our product offers an incredibly rich set of features including our incredibly fine grained permissions, and we don't want to compromise the offering; that said, we can absolutely do better on CMS performance and we will be working on improving this in the future.

Just to be sure and make more clear,
Are you saying it's OK NOW to run a site with several hundreds active users in the same time on a shared hosting? Or do you recommend to disablethe CMS in such cases till the this queries problem resolved?

[Nick]

Perhaps the high query count isn't something we should be worried about as much as we think...
vBulletin 4 Coding Quality
http://www.adminaddict.net/forum/vbu...ex4/#post57050

[smooth-c]

Whilst it's frustrating, I don't see why people keep on enthasising that we've lost features - we've lost a feature that is returning in a point release.

[Grover]

Whilst it's frustrating, I don't see why people keep on enthasising that we've lost features - we've lost a feature that is returning in a point release.

Trust me, we have lost a lot more then 1 feature. We have not only lost a fair amount of previous (good working) functionality (Search is one of them), but most importantly, the majority of vocal once dedicated customers people overhere and on the internet lost... their trust in this product due to the way this new company is handling their product and customer relationships with it... I have never ever witnessed so much negativity and bad press on the world wide web about vBulletin and it keeps saddening me. It sincerely is hurting to see it happening, when you realize that Jelsoft had build a legendary solid, professional, trustful product and ditto customer relations. Granted, in the last years Jelsoft was unable to meet the requirements of today's internet market (what I've understood, management did not dare to hire new developers) and now that we do have more developers at hand, this product and customer relations are handled (read: managed) so badly, that it has hurt this product and it's name indefinitely. And for me that is certainly difficult to experience, which goes for everything you love. I loved this once fantastic product. I mean it when I say that when I read some management Blogs overhere and even certain support postings I have a hard time taking them seriously anymore, because of the fact that they seem completely out of touch with reality.

For me, IB really needs to get their act together in 2010, on their way from 4.1 to 5.0, otherwise the future will look very dark. I still can not grasp it... how an internet company consciously generates such an enormous amount of bad press about their internet flagship product. We have all read it in the leaked information: vBulletin never did advertise much... the product became successful due to it's excellence and mouth-to-mouth advertising. And this, the mouth-to-mouth discussions all over the internet about vBulletin, have become intensively negative around the world in recent months. How can one ever recommend this product anymore (which I did in the past) if potential clients read so much bad press when they Google vBulletin today?

As a simple (once very dedicated and proudly promoting) customer I do not understand anything about managing things, but if I was managing my own flagship product I really would feel ashamed if I released a product as Gold which clearly does not deserve that title at all. I would feel ashamed about myself and my customer relations. Yes, even if words come across differently/heavier then intended when writing things down, I do feel emotional about it. Apparently, like former developers stated already, there are different priorities nowadays and it clearly has shown this unfortunate year, hasn't it?

I will light a candle and hope for a miracle in 2010 and the near future...

To the current developers I want to say: thank you for listening to our suggestions and your interaction on the Suggestion forums and PM's: this is very much appreciated. I hope that there comes a time (soon) that vBulletin will be a state of the art product again and that the quality of the future product by itself can turn things around for the product and the community (who play a big part in the success of vBulletin, certainly nowadays).

[Alfa1]

I have a few questions too that are important for me. I would appreciate your reply.

1. A lot of folks have mentioned the high query count on CMS; I think 'query count' is a misleading metric. The real question is: how long does it take to render the page? We've made a number of fundamental changes to the DB schema in 4.0 that improve performance in a variety of areas, and some of the improvements have changed the way we approach some parts of the application design. In the case of CMS we would rather have a lot of tiny queries that take a few milliseconds each than a few large joins that take hundreds of milliseconds. Our product offers an incredibly rich set of features including our incredibly fine grained permissions, and we don't want to compromise the offering; that said, we can absolutely do better on CMS performance and we will be working on improving this in the future.

My site already needs to be able to cope with many hundreds of connections at the same time, without having pages with hundreds of queries. Surely it matters what queries they are, but show me some high traffic boards coping with the CMS and maybe I'll dare to install. Currently I would not dare.

1. Can you show me a vb4 site with many thousands of concurrent users? Does it work fast?
2. I understand that all content types are going to be part of the CMS. So the CMS should be the basis. Once that is ready, we have something we can work with and develop on. Currently it has CMS content types, but no CMS comments. The old forum is used for the new content types. So its nowhere near a complete fundament. When will there be a complete basis? i.e. a CMS with content types that work completely within the CMS?
3. While Blog, groups and albums are coded with vb4 in mind they are still not integrated, nor CMS content types. So there are various isolated systems within vb: blog, groups, CMS, forum, forum side bar, albums. That makes it very messy. When* can we expect blog, groups and albums in the CMS?
4. And search has gone from not-integrated to an absolute mess. vb4's search is not even usable as it does not display chronological results and has various bugs. This is another show stopper for me. When* can we expect the search engine to be fixed? Or are we expected to move to sphinx?

*With 'when' I am not asking for a specific date. Just an indication and if it will be in a 4.0x release or in a 4.x release.

[Mark.B]

Good questions, thanks. As I mentioned before, 4.0 is a new release and has some of the short-comings of a new release while still also having overwhelming value (in my opinion). I'll try to answer the specific questions above as best as possible:

1. A lot of folks have mentioned the high query count on CMS; I think 'query count' is a misleading metric. The real question is: how long does it take to render the page? We've made a number of fundamental changes to the DB schema in 4.0 that improve performance in a variety of areas, and some of the improvements have changed the way we approach some parts of the application design. In the case of CMS we would rather have a lot of tiny queries that take a few milliseconds each than a few large joins that take hundreds of milliseconds. Our product offers an incredibly rich set of features including our incredibly fine grained permissions, and we don't want to compromise the offering; that said, we can absolutely do better on CMS performance and we will be working on improving this in the future.
   
2. Regarding personalization/custom profiles: look for this in one of the upcoming point releases.
   
3. As far as the QA process and high bug count: our QA process has been improving constantly throughout the last phase of the development cycle. We think we've delivered a better product, faster than anytime in the history of vBulletin and we will continue to drive new feature development while maintaining high quality. We have recently hired more QA and engineering staff to help out. For more detail on the process we have used and are using, please see my previous article.

I hope that helps give some insight into where we are at. I'm very proud of the great work the team has done on 4.0 and I know that there is a lot more to come.

Joe; thank you for taking the time to respond to this thread.

I accept most of your points - my only concern is on the CMS query issue. Many vB customers are on small shared hosts, and that huge query count will cause them issues with their hosts. The hosts will not look at the time the page takes to load, they will say "200 queries - overuse of MySQL resources, account suspended".

Of all the issues with vB4 Gold, I *implore* you to get this issue fixed before any other. It will honestly kill the CMS as a viable product, which is a great shame since it looks and feels really good.

Myself, I'm on a VPS that could probably handle the query count, but it's the smaller customers I'm speaking for here - alienate these and vB will struggle.

This isn't a complaint, I like the direction vB is going, it's a piece of advice from someone with the best interests of the product in mind.

[Floris]

Query count for version 4 not important and has no effect for vBulletin's performance.
[noted]

Learned something new.

[Paul M]

[*]A lot of folks have mentioned the high query count on CMS; I think 'query count' is a misleading metric. The real question is: how long does it take to render the page? We've made a number of fundamental changes to the DB schema in 4.0 that improve performance in a variety of areas, and some of the improvements have changed the way we approach some parts of the application design. In the case of CMS we would rather have a lot of tiny queries that take a few milliseconds each than a few large joins that take hundreds of milliseconds.

You might just win that argument if you were running just a few extra queries per page, but when you are running a hundred extra, it just doesnt stand up - and will impact a large number of customers on shared hosts, seriously in some cases. Even if a shared server is running just 10 sites, thats a thousand plus extra queries - it doesnt matter how small they are, thats going to hurt, and hosts will start taking action against the sites causing it - not to mention the hosts that actually restrict the number of queries per hour (yes, hosts really do that).

The team really need to take a serious look at why so many are being run (many of which are almost identical) - and for starters, cache the templates - that's been a known issue since Alpha - there is just no valid excuse for 20+ uncached templates in the gold release.

[Reeve of Shinra]

Joe,

thank you for taking the time to reply. I'm still not clear on why the CMS has so many queries...

While vbadvanced has certain challenges when it comes to adding article like content, as a portal it works perfectly and uses relatively few queries even with the # of 'widgets' it has running.

WordPress also has relatively few queries and it's quite fast. I'd even go so far as to say that it currently exceeds the CMS in every area except native integration with the forum.

I could have paid for better integration but I opted for the suite. If IB has not intent of living up to it's promises, should we rethink our purchase and look towards alternatives?

[Dave B]

Good questions, thanks. As I mentioned before, 4.0 is a new release and has some of the short-comings of a new release while still also having overwhelming value (in my opinion). I'll try to answer the specific questions above as best as possible:

1. A lot of folks have mentioned the high query count on CMS; I think 'query count' is a misleading metric. The real question is: how long does it take to render the page? We've made a number of fundamental changes to the DB schema in 4.0 that improve performance in a variety of areas, and some of the improvements have changed the way we approach some parts of the application design. In the case of CMS we would rather have a lot of tiny queries that take a few milliseconds each than a few large joins that take hundreds of milliseconds. Our product offers an incredibly rich set of features including our incredibly fine grained permissions, and we don't want to compromise the offering; that said, we can absolutely do better on CMS performance and we will be working on improving this in the future.
   
2. Regarding personalization/custom profiles: look for this in one of the upcoming point releases.
   
3. As far as the QA process and high bug count: our QA process has been improving constantly throughout the last phase of the development cycle. We think we've delivered a better product, faster than anytime in the history of vBulletin and we will continue to drive new feature development while maintaining high quality. We have recently hired more QA and engineering staff to help out. For more detail on the process we have used and are using, please see my previous article.

I hope that helps give some insight into where we are at. I'm very proud of the great work the team has done on 4.0 and I know that there is a lot more to come.

WE are saddened that the standard of what was once a great product, once backed by great management has been lowered to such an extreme. Worse than putting out a poor product is being proud of it.

Once upon a time any marketing speak put forth by team VB was worth the benefit of doubt. Does it bother team VB that this is no longer the case and marketing speak no longer has any affect other than a quick giggle or maybe a bit of anger?

[ManagerJosh]

Good questions, thanks. As I mentioned before, 4.0 is a new release and has some of the short-comings of a new release while still also having overwhelming value (in my opinion). I'll try to answer the specific questions above as best as possible:

1. A lot of folks have mentioned the high query count on CMS; I think 'query count' is a misleading metric. The real question is: how long does it take to render the page? We've made a number of fundamental changes to the DB schema in 4.0 that improve performance in a variety of areas, and some of the improvements have changed the way we approach some parts of the application design. In the case of CMS we would rather have a lot of tiny queries that take a few milliseconds each than a few large joins that take hundreds of milliseconds. Our product offers an incredibly rich set of features including our incredibly fine grained permissions, and we don't want to compromise the offering; that said, we can absolutely do better on CMS performance and we will be working on improving this in the future.
2. As far as the QA process and high bug count: our QA process has been improving constantly throughout the last phase of the development cycle. We think we've delivered a better product, faster than anytime in the history of vBulletin and we will continue to drive new feature development while maintaining high quality. We have recently hired more QA and engineering staff to help out. For more detail on the process we have used and are using, please see my previous article.

I hope that helps give some insight into where we are at. I'm very proud of the great work the team has done on 4.0 and I know that there is a lot more to come.

It's great that you're running several smaller queries. However at the same time, other factors must be considered, such as how many concurrent connections could a user have to a SQL server. It's fine and dandy to me if those few hundred queries are completely efficient queries, but thus far all the queries running back and forth suggest to me that the existing queries are completely inefficient.

Regarding the query count Joe, do you have any actual performance data that can back up your claim that the current query count is a misleading and that a vBulletin 4's CMS would not be bringing down servers for having 100 concurrent users? Or perhaps 1000 users? How about 5000 users? As they say, cheap is talk. Show us your testing variables, your testing environment and what was done to perform tests.

Until such data is provided to alleviate our fears, your claim is totally hypothetical and theoretical. Stress testing is very much a part of QA.


Furthermore, I think you're also confusing the issue here. Page rendering is one matter, but so is query count. For me, query count is completely backend with no variables coming from an end-user's computer. With page rendering, we need to factor in an end-user's computer because they have multiple variables, including what browser they run, what type of javascript engine is utilized, bandwidth of a user, and so forth.

Therefore Page-Rendering itself is quite subjective. It encompasses factors that are sometimes uncontrollable. However, queries are completely independent and manageable by developers. They supply the necessary building blocks to do page rendering in the first place.



Lastly, looking at QA, I respectfully disagree. I feel it is a very naive assessment and that to believe your claim would essentially be wearing rose-colored glasses. I've done a lot of QA in my lifetime. I still do QA for several Fortune 150 and 500 companies. I've learned a lot during the QA process and that includes not everyone can do QA. As I go through doing some of my standard mis-use cases, I am finding things that should have been caught were not caught during the QA process. My standard list is also very shallow. Given the finite time I have right now as I am rebuilding a series of sites and in my studies, I've yet to attempt some of my more complex bag of tricks I use for QA to break things.

Lastly, If I was your lead QA tester, and Internet Brands released vBulletin 4 in this current state, I would be extremely embarrassed. I would not even want my John Hancock on it. Bugs are always going to be there and I know that first hand. But I can't ignore what my own personal experience tells me and that is this entire project has been completely mishandled and that there are far too many bugs for me to sign off on a release.

[Cap'n Refsmmat]

It's my assessment that if management has to argue against the many criticisms leveled against it, there's something wrong.

If you're being criticized from all directions, you might argue that the criticisms are misguided or wrong, but that still leaves the question of why are you being criticized so much?

IB might be telling itself "no, they don't have it right, the quality is great" but that doesn't change the fact that something has made hundreds of customers unhappy.