Can someone help me understand why yesterday the GA2 release date on the roadmap page was listed as May 11th and now today it is showing as June 8th?: http://issues.liferay.com/browse/LPS#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel

Can someone help me understand why yesterday the GA2 release date on the roadmap page was listed as May 11th and now today it is showing as June 8th?: http://issues.liferay.com/browse/LPS#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel

Is it ever safe to rely on the date listed there?

Same exact question here!I have delayed an installation for a new client based on that schedule.Till friday afternoon there was no clue about a change (a full month), neither on forums nor on twitter.No clues before, no explanations after.It's a little disappointing, especially when you have to justify a broken promise to your client...What happened?

The date in JIRA is our target date but it's not set in stone so it is subject to change. We have a lot of dependencies for this release with Marketplace and Social Office. If you need predictability and SLAs then I'd suggest going with EE.

To both:Just to share a thought with you and not making a flame about thisI'm not deep into Liferay (as I would like to be), since I'm striving since at least a year to switch our current CMS to LR.

Making a long story short and omitting many details, CE is a "bridge" to making a choice about EE adoption, so first, IMHO, you go CE for some projects for some months and when all is fine you can offer to your clients/Boss to switch to paid version (with support and SLA and other things).And by the way, that MY personal aim (I'm a developer with a little "steering power" ), so I'm NOT against choosing paid EE at all.

That said, for the specific case, since CE stands for Community Edition, I guess that maybe a forum post or a little tweet from Liferay staff anticipating that this week planned CE release won't cut it, would be appreciated by the community itself, instead of a shift of 4 week the next time that you go to see the "due date" page field.I had seen in some posts that 6.1.1 GA2 has been delayed since mid-february/march and have seen that current bug fixing graph on Jira is practically on break-even point, so , yes, I 'hoped" that there shouldn't have been issues about the planned release and that, if were there delays, would have been some days.So yes, I guess I should have had "bytes at hand" :-) before making an (informal btw) agreement.

So, it's not a tragedy to me now, but, is it possible to share some kind of up-to-date info about the releases (and/or major LR-Related events) to the Community, maybe just via Twitter or something, please? Hope not appearing offensive about this kind of "Community Communication Enhancement Request" ;-)

Thanks for sharing Diego. You are absolutely right we should communicate possible missed release dates more openly and earlier to everyone but we are still working on our internal processes so that we have better visibility to delays. As a former community member I do understand that we don't communicate enough with the community although James Falkner our community manager has greatly improved that. BTW waiting 6.1.1 myself too to upgrade my own site.

The 6.1.1 CE GA2 is still in progress: 610 of 619 issues have been resolvedDoeÄS anybody know it will be released in this month an can I use der Plugins from 6.1.1 CE GA2 with 6.1.0 CE GA1?(I could not compile SVN-Versions of some, because of new annotations in GA2)ThanksFrank

I don't think anybody including most of Liferay.com staff actually can state that it will be released this month or not.Several Liferay.com staffs have posted here about the release dates earlier before but they all turned out to be false alarm.

can I use der Plugins from 6.1.1 CE GA2 with 6.1.0 CE GA1?

Plugins for newer versions usually don't work with older versions because liferay.com often changes the api and sometimes variable names too.

I think I'm going to conclude that the next release is probably going to be somewhere in fall from liferay release cycle.

The release date that was first given as sometimes in April may have been a bogus by a marketing teamto make users try to use a very buggy 6.1.0 and to switch to purchasing the EE version.

The bottom line is, don't use the 6.1.0 CE version because the quality is sub-standard. Either purchase the 6.1 EE version or stick with the 6.0.6 CE version.

I'm really sorry that we don't communicate better - I tried with 6.1.1 and Marketplace but we're just not at a point as a project to be able to definitively say 6 months out when a release will be ready. It's more like 7-10 days, and we're not within that window yet. Normally, we pick a cutoff date internally, then once we reach that date, the code goes into several test rounds - after the first one, we're fairly confident that it'll be ready after the final QA round, so we can talk definitively about that. This GA2 release is special as Mika pointed out - lots of interdependencies between GA2, Marketplace, and SO 2.0. So most of the issues we've found as due to that interdependency, so we keep delaying. My hope is that once we're over this hurdle, the next ones will be smoother. I think I speak for everyone when I say thanks for all of your collective patience and I promise to work on our communication.

I think it's just not me who feel a little bit disappointment because I believed that community involved bug squad and verifier programs were meant to help speed up community releases and I would be able to see and show others the output from the involvement.

I think it's just not me who feel a little bit disappointment because I believed that community involved bug squad and verifier programs were meant to help speed up community releases and I would be able to see and show others the output from the involvement.

The output from those programs (bugsquad and verifier) is in the 6.1 GA1 release and will eventually be in GA2, so do not worry about that! But the GA2 delay is not something those programs could have helped.

This brings a good point.It would be nice to at least see the patches for bugs and issues that resulted from the bug and verifier community project available to the community by now. I thought the end date was determined based on the planned release date.

Please stick with the current target date and release Liferay 6.1.1 CE GA2 even if there are unfixed issues! Any unresolved issues not fixed by july 27th should be moved to GA3.

We're using Liferay for our student portal and for almost a year, we have been planning to use Liferay in a more extensive way. Liferay 6.1 introduces major differences in the UI so we have installed 6.1.0 GA1 in our test environments to allow the teams resposible for managing the portal to learn the new environment.

All of our teams efforts to create new organizations, sites, templates etc. has been made for 6.1. We've also put off improvements and new development within our existing Liferay version and have instead been working with the 6.1 API.

Since the GA1 version is not fit for production, we have been trying to assure management that 6.1.1 GA2 will be released before the fall semester. As the release date keeps pushing forward, I'm starting to get very worried. We will be in a very difficult position if all the work that's been put into 6.1 won't be available for the fall semester.

It's been said (see Mikas answer above) that we should get the EE version if we need predictability. I understand and accept this point of view. There's a good chance that we will get the EE version if this project works as well as everybody hopes. But in our current process, we really need to get GA2 to become operational.

You're all doing a great job with Liferay, believe, hope and pray that GA2 will be released on july 27th

Here's the thing. The GA2 wont be production ready either. nor will GA 9001 be. They want you to buy the enterprise edition. It's best to give your management the bad news now.

Truth be told. If you don't get the support, a license is not *that* expensive. But I think most people would have chosen a different platform had they known about this up front. I know i would have.

I guess a group of dedicated people could always decide to fork the Liferay codebase, and put in an effort to stabilize the community editions and make them production ready but so far this hasn't happened.

Here's the thing. The GA2 wont be production ready either. nor will GA 9001 be. They want you to buy the enterprise edition. It's best to give your management the bad news now. .

Sorry Jelmer, don't agree at all.

Liferay has always had some delay between GA versions, so don't see any weird thing here.

In this case they have to launch Marketplace (which implies huge internal/external changes as I can see in everydays source commits).

jelmer kuperus:

I guess a group of dedicated people could always decide to fork the Liferay codebase, and put in an effort to stabilize the community editions and make them production ready but so far this hasn't happened

I've been uploading Liferay 6.x.x patches for different CE editions since 2009 (this time will do the same). But forking the whole project would be a real huge effort, and probably won't meet anyone's quality requirements. I prefer being more patient (I know this isn't easy sometimes) but get a product with more quality, even with delays.

Nor was I implying any such thing. If anything i am acknowledging that this is business as usual

As far as I am aware the release dates of all previous releases have slippedAs far as I am aware there has never been new community edition release just to fix a dangerous security vulnerabilityAs far as I am aware none of the community editions have been production ready.

Assuming that the new GA will somehow make the community edition production ready is just wishful thinking. If you are using Liferay in production you should just get the enterprise edition. This is the message he should be getting across to his manager.

But forking the whole project would be a real huge effort, and probably won't meet anyone's quality requirements.

I am thinking more along the lines of backporting fixes to the community edition and doing regular releases. Patches are all nice and dandy but most people just want to be able to download a zip file that works.

In this case they have to launch Marketplace (which implies huge internal/external changes as I can see in everydays source commits).

Juan, I don't think anybody is really complaining about the time it'll take to implement Marketplace but more about the practice about repeatly giving a release date and extending it over and over again. If developers at liferay.com really can't project how much resource and time it's going to require to develop a feature, they shouldn't be providing professional service (e.g. setting up and customizing liferay for customers) to customer sites. Why can't liferay.com just say that it's going to be available this fall h and if they got some time leftover after the implmenting Marketplace, fix more bugs until the announced release date?

With v6.0 CE I waited till GA3 (6.0.5) and then upgraded to GA4 (v6.0.6) when it came out. That v6.0 CE experience has led me to only use the v6.1 GA1 to start reviewing new features - which are so cool - yet I have to be patient with my own impatience and I likely am going to wait for a GA3 or 4 before thinking of using a CE v6.1 GA* for anything real.

I like the way Artur Signell of Vaadin expressed a release delay like at: https://vaadin.com/blog/-/blogs/vaadin-7-alpha2-delayed: "We do not want to release a semi-broken *versionReferenceHere* that would disappoint most of you so we have taken the liberty of pushing the release date forward until we feel we have a second *versionReferenceHere* version that people can enjoy." Now that is art-ful communication.

With advertised 'anicipated' released dates the likes of Q1,Q2, Q3, Q4 of such and such a year, where if delayed there comes a communication like above - such might be help manage expectations.

Juan, I don't think anybody is really complaining about the time it'll take to implement Marketplace but more about the practice about repeatly giving a release date and extending it over and over again. If developers at liferay.com really can't project how much resource and time it's going to require to develop a feature, they shouldn't be providing professional service (e.g. setting up and customizing liferay for customers) to customer sites. Why can't liferay.com just say that it's going to be available this fall h and if they got some time leftover after the implmenting Marketplace, fix more bugs until the announced release date?

I'm so glad to see this thread and I completely agree with your comment, Hitoshi. For months, nearly a year, we have been evangelizing and planning for 6.1. We knew it would take some time and have been so patient. I was thrilled when 6.1 GA1 came out earlier this year despite its bugs. Then, we were told GA2 would be coming weeks after 6.1 EE because of the number of problems with 6.1 GA1. We have hinged our entire summer project line on GA2, first expecting it in April, then May, then June, and NOW?! July... and the end of July at that. At this point I don't know what to do. Could we wait until July 27? Probably...but I really can't sit here and believe that July 27 is the date based on experience.

We have been seriously considering purchasing EE in the future but that's going to be a really difficult sell when I have to keep pushing our initial project back and can't prove what this can really do for us.

I understand the dependencies on Social Office, Marketplace, etc. These things happens. However, I see no reason GA2 can't be released without fixing all the dependencies for those products if they're not ready right now. Why not release GA2 on it's own and then when SO 2.0 and Marketplace are ready release GA3, GA4 to address the dependencies of those other products?

My 2 cents. I hope we can see some good come from this. If there's any way the community can help with this I would love to hear it. How can we improve communication?

That's what I use as the indicator that a version is ready for primetime. When Liferay.com upgrades to the 6.1 line (even though they're running EE), I'll know that the 6.1 CE line has stablized enough to become usable.

And I look forward to when that will happen, just like everyone else.

In the meantime, if you're prepping a site that will not go live anytime soon, I'd still base it on 6.1. Why build it in 6.0 only to face upgrading later on?

But if you need to be live soon, I'd stick w/ 6.0.6. Will get you up and running on a stable platform and you can delay the move to 6.1 until it is production-ready.

Thank Drew, I think even James said the cut date off of the verifier project was set based on the GA2 release date. The community answered to their help and got it but they really haven't replied back to the community yet. It will be a real disappointment about their business ethics if this repeated delays was actually based on marketing ploy.

Assuming that the new GA will somehow make the community edition production ready is just wishful thinking. If you are using Liferay in production you should just get the enterprise edition. This is the message he should be getting across to his manager.

I think this is insufficient. If I'm going to use any software in production, I'll first check if it really works and the support available is sufficient. I don't think it about CE and EE. If the feature in EE doesn't work and the developer is unable or unwilling to fix it, it's completely useless.

Assuming that the new GA will somehow make the community edition production ready is just wishful thinking. If you are using Liferay in production you should just get the enterprise edition. This is the message he should be getting across to his manager.

I think this is insufficient. If I'm going to use any software in production, I'll first check if it really works and the support available is sufficient. I don't think it about CE and EE. If the feature in EE doesn't work and the developer is unable or unwilling to fix it, it's completely useless.

I'm sorry that we've had to constantly delay the GA2 release - I promise you there is no marketing ploy or conspiracy to trick people into doing anything. That's not Liferay's culture or intention, and if it was, I'd be the first of many to bail out.

I'll give a more thorough response but I'm getting on a plane to LA and we'll sort this out with a more thorough response tomorrow. We're working on improving things and learning a lot through constructive threads like this one. So hang in there!

James, I know that you'll actually not the one who is delaying the releases because I know this is hurting the community more than it is doing any good.

I'm involved in seveal commercial and non-commercial open source projects and we are partnership with several overseas software companies too.Software delays are common to the point that it's more rare to see software released as scheduled, but I haven't see this repeated announcement ofshort term delays caused by technical teams. If this was a system integration project, you'll be out the door by the third reschedule request.

Also, Liferay.com requested the community to help them to find bugs and verify them so the new release will be more bug free and can be released in a shorter time frame. Getting the "prize" is fun, but I'm sure that many community members got involved to see a more bug free software released in a short period of time. Liferay.com made community members "believe" what was untruth - intentional or not.

You've mentioned about Marketplace, but is the request to delay coming from Brian or Jorge or by Paul or Bryan?

we tryed the folllowing revisions and for the moment it worked for us and our LR 6.1 GA1, but we are not sure,how to merge future bug fixes ....portal: http://svn.liferay.com/repos/public/portal/branches/6.1.x rev 99607

It is a pity that the GA2 is delaying for such a long time and there are so many incompatible changes regarding the predecessor ;-(In this special case we would prefer, to consider an interim bug-fix-release

It's completely almost criminal to not resolve these issues on the community edition

Seriously heinous.

We're setting up the team now to handle community security fixes, so hang on.

Any news on this new team? I understand that LifeRay's focus is on EE, but there should be a mechanism in place for CE users to see known security issues and at a minimum see the associated commits for fixes if they exist.

While they're all together be sure and bring up how easy security bugs fixed in prior versions manage to leapfrog 6 releases and appear in a different major number GA 6 release and how that can be prevented. Embarrass the hell out of me, got a huge political contingent of haters trying to kill it here that don't need any more ammunition.http://issues.liferay.com/browse/LPS-22979How conspiracy theory get started and rumors so ugly projects never recover from them start flying. If it can't be secured it's not even worth poking with a stick much less installing. Marketing may not understand that major security issues are the sort of thing that make people buy Sharepoint instead, just makes the entire product line look really, really bad. The company would probably be better served to kill off CE than release it like that.

Thanks for your constructive input. I'd like to respond to several of the points mentioned:

Can someone help me understand why yesterday the GA2 release date on the roadmap page was listed as May 11th and now today it is showing as June 8th?: Is it ever safe to rely on the date listed there?

We have struggled with supplying realistic due dates for this particular release, due to the number of interdependencies between Marketplace, Social Office 2.0, and Liferay Portal. For example, LPS-26321 implements a Java SecurityManager for securing plugins, and has taken some time to implement properly. It's finally done (woo!) and we can press forward with the Liferay release and Marketplace. There are a few more like this. Even prior to this though, we have not always hit our release dates, and is something we intend to improve by keeping everyone informed about progress with more detail, and better notification when hit or miss our dates.

The date in JIRA is our target date but it's not set in stone so it is subject to change. We have a lot of dependencies for this release with Marketplace and Social Office. If you need predictability and SLAs then I'd suggest going with EE.

Even with EE subscriptions and the associated SLAs, it won't improve our ability to predict the future. Even if you had an EE subscription today, you still wouldn't have EE GA2 in hand.

So, it's not a tragedy to me now, but, is it possible to share some kind of up-to-date info about the releases (and/or major LR-Related events) to the Community, maybe just via Twitter or something, please? Hope not appearing offensive about this kind of "Community Communication Enhancement Request" ;-)

There are many community members involved in the production of a release, and they don't always talk to each other, and that is something that must improve. Jorge Ferrer had an excellent idea many months ago -- a releases page that details which releases are current (with associated release notes pointers, upgrade information, etc), and which are "on the drawing board" -- with their current status, which is updated as often as necessary to keep everyone in the loop. That's going to be implemented very soon. I hope to have this in place next week.

My personal opinion is that it's better not to publicized a "target release" date that's going to change. It would be better if a date that is going to change be kept just internally.

I'm one of the people asking for release date, but it doesn't do me any good to have a date that's going to change so often. It's just better to hear that you've haven't really set it yet.

One of the results of the discussions regarding security issues is that we are going to do releases more often (along with associated patches for security issues for CE in the interim, see below). So, rather than one big date for one big release, we get to a point where we consistently do new releases every 3 months or so, at least giving you some amount of predictability.

The release date that was first given as sometimes in April may have been a bogus by a marketing teamto make users try to use a very buggy 6.1.0 and to switch to purchasing the EE version.

I strongly disagree with that -- we are not out to trick anyone into doing anything. Every single CE release is one that we feel can be used in production *at the time of its release*. We do not have 100% code coverage in our unit and integration tests, but that's very difficult to achieve with a large code base. And as humans, we make mistakes and miss things that we learn from and hopefully never repeat. And it is easy to look back and say that a particular release is too buggy, but that is not and never will be our intention.

I think it's just not me who feel a little bit disappointment because I believed that community involved bug squad and verifier programs were meant to help speed up community releases and I would be able to see and show others the output from the involvement.

Bug Squad was a *huge* help in uncovering usability and functional bugs in 6.1.0, so the team can be proud of its accomplishments in helping improve many of the features and usability aspects of 6.1. With the verifier program, the "output" is not as satisfying, but still results in the community having less bogus bugs to deal with. So those programs do produce fruit, some of it more visible and tasty than others.

While on the subject where is the "fix" for these serious security fixes I was promised

It's almost criminal to not resolve these issues on the community edition

Liferay, like all other web-oriented software, can never claim to be 100% secure and free of security bugs like those above. Jelmer and others in the community have done an awesome job finding and informing Liferay of its shortcomings, and the community is very appreciative of their work. Liferay's growing popularity means there are more eyes looking at it, more people using it, and more people finding the "dirty laundry" bits. This is what open source is all about, right? In the past, we have relied on new CE releases to fix these issues, but spinning new releases takes a lot of effort on our part, due to the way the product is constructed. While that can and certainly should improve, we are taking steps in the community now by forming a new community security team which will begin creating CE patches for critical security fixes, while at the same time doing new releases more often. Details on this team and its charter will be made shortly.

As far as I am aware the release dates of all previous releases have slippedAs far as I am aware there has never been new community edition release just to fix a dangerous security vulnerabilityAs far as I am aware none of the community editions have been production ready.

Assuming that the new GA will somehow make the community edition production ready is just wishful thinking. If you are using Liferay in production you should just get the enterprise edition. This is the message he should be getting across to his manager.

Again, CE is not a "carrot" we dangle in front of prospective customers in the hopes that they try it, like it, find issues, call us, and we hit them up for money. For customers who do not want or need the added benefit of ready to use patches, support SLAs, indemnification, extra features, etc, we want them to use CE in production (and hundreds of thousands do), and we produce CE with that in mind. I, along with the rest of the company and community, want CE to be the best that it can be. CE sites make us no direct revenue, but Liferay has always been about more than revenue and the bottom line. Yes, CE has bugs. So does EE. So does every other piece of non-trivial software. Liferay is committed to producing quality open source software and has built its business around that.

I am thinking more along the lines of backporting fixes to the community edition and doing regular releases. Patches are all nice and dandy but most people just want to be able to download a zip file that works.

That's exactly what the Community Security Team will do, so you're in luck!

As I stated above, I can only conclude that the repeated release date of the CE version is intentional marketing to lure users like you to purchasing EE subscription.

Again, I strongly disagree with your conclusion. Using marketing as a tool to trick users into buying our software is unethical and strongly goes against all that Liferay stands for.

Unfortunately, I don't think the new release is going to be out in July. I've heard James say the same thing about it becoming available in few days few months back.

I think people at liferay.com are going to end up repenting for this sin about this later because people are not that dumb to believe them ever again.

We are experiencing the typical pains of a growing company and project. That's all. It's very common for this to happen, and there is no conspiracy afoot, I can assure you.

Juan, I don't think anybody is really complaining about the time it'll take to implement Marketplace but more about the practice about repeatly giving a release date and extending it over and over again. If developers at liferay.com really can't project how much resource and time it's going to require to develop a feature, they shouldn't be providing professional service (e.g. setting up and customizing liferay for customers) to customer sites. Why can't liferay.com just say that it's going to be available this fall h and if they got some time leftover after the implmenting Marketplace, fix more bugs until the announced release date?

We are going to do better at communicating information about the release cycle of Liferay. Unfortunately, it is difficult sometimes, especially when you have multiple releases depending on each other. In hindsight, that is probably not something we will repeat.

I like the way Artur Signell of Vaadin expressed a release delay like at: https://vaadin.com/blog/-/blogs/vaadin-7-alpha2-delayed: "We do not want to release a semi-broken *versionReferenceHere* that would disappoint most of you so we have taken the liberty of pushing the release date forward until we feel we have a second *versionReferenceHere* version that people can enjoy." Now that is art-ful communication.

With advertised 'anicipated' released dates the likes of Q1,Q2, Q3, Q4 of such and such a year, where if delayed there comes a communication like above - such might be help manage expectations.

Yep, that's a very good example. In the past, when we miss a release date, we as a company tend not to communicate, for fear of being wrong again. I think we can do better at informing the community of the current release status, and if there are any delays, a reasonable reason for it. This is something I intend to do going forward.

I understand the dependencies on Social Office, Marketplace, etc. These things happens. However, I see no reason GA2 can't be released without fixing all the dependencies for those products if they're not ready right now. Why not release GA2 on it's own and then when SO 2.0 and Marketplace are ready release GA3, GA4 to address the dependencies of those other products?

My 2 cents. I hope we can see some good come from this. If there's any way the community can help with this I would love to hear it. How can we improve communication?

We are learning from this experience, and you all have helped tremendously in this regard. We want the release out as quickly as possible, with the highest possible quality, so the work that you and others are doing in the community to help has been outstanding, and I hope that it continues.

Also, Liferay.com requested the community to help them to find bugs and verify them so the new release will be more bug free and can be released in a shorter time frame. Getting the "prize" is fun, but I'm sure that many community members got involved to see a more bug free software released in a short period of time. Liferay.com made community members "believe" what was untruth - intentional or not.

You've mentioned about Marketplace, but is the request to delay coming from Brian or Jorge or by Paul or Bryan?

The programs in our community certainly do result in less bugs and a shorter release cycle - every release done after bugsquad and the community verifier teams have done their work has had less bugs than if they did not do that work - so for that, everyone that was involved in those programs should be proud of the work they did and continue to do. We hold as a value and goal the ability to keep our release dates, regardless of CE or EE. No one is "requesting" that there be a delay -- we want the release out as quickly as possible, and with quality, but we will slip the date in order to meet that goal. What we have not done a good job at is communicating to you when a slippage occurs, and the reasons for it.

How conspiracy theory get started and rumors so ugly projects never recover from them start flying. If it can't be secured it's not even worth poking with a stick much less installing. Marketing may not understand that major security issues are the sort of thing that make people buy Sharepoint instead, just makes the entire product line look really, really bad. The company would probably be better served to kill off CE than release it like that.

Liferay is committed to producing secure products (both CE and EE), and we are taking steps to improve this even more through the newly formed Community Security Team. The "tl;dr" of this is that the team will make security patches for CE, keep the community informed of newly discovered vulnerabilities (and their workarounds and fixes), help to do more "full" CE releases more often, and educate developers internally and externally how to prevent such bugs in the first place.

In summary, we do not ever intend for CE to be a watered-down version of Liferay in the hopes that it results in an EE sale. The community should be proud of the innovations it has consistently driven into the project. Delays in releases are challenges that many growing companies face, and are never purposely done in order to drive sales of a "good" version, and such delays must be better communicated. We are serious about security, and are taking steps to improve this as stated earlier. I believe we can see the light at the end of the GA2 tunnel now, and my hope is that going forward the improvements will be dramatic and obvious, and you will continue to contribute to and champion Liferay and its benefits.

I thought I would weigh in on this thread. The slipping dates can be frustrating at times but I do know they have good reasons for delaying things.

Here's a few things that I have seen covered above and my thoughts on them.

Release Dates

Usually when I quote a date to people I explain to them that this is a development target and not set in stone. I also explain that missed dates are usually due to blocking security or quality issues. In most cases this usually goes over well because they would rather have a secure and less buggy release than one full of problems.

I think smaller releases would really help with a lot of the perceptions I am seeing. I know Liferay typically likes to do everything and the kitchen sink releases which tends to be one of the main factors in delaying releases. Because if a release has everything and the kitchen sink then there is more room for quality issues and security problems. Agile preaches small iterative releases with quicker release cycles to help mitigate a lot of these issues. So if Marketplace or Social Office doesn't make the cut by the end of a cycle then they go into GA3.

I know it was mentioned that a team would look at providing security patches between the CE releases. Does this also extend to regular bug fixes? It would also be nice to see patches for these as well.

Quality of CE releases

I for one thought 6.1 CE was one of the best releases I've ever seen. During the Bug Squad I upgraded our 6.0 EE SP1 environment to it many times. I thought the quality was on par with 6.0 EE SP1 if not a little better. Would it be possible to post some of the stability issues with 6.1 CE that everyone is holding out for GA2 on?

We migrated over to Liferay from a competing portal product and I assure you the quality of Liferay Portal 6.1 CE far surpasses the proprietary heap of crap that we were paying 6 digits for.

I was getting the impression from above there were stability concerns alongside the security ones which is why I specifically asked about stability issues since I haven't witnessed any stability problems myself. My apologies for not being clear. I understand the security issues are very serious which is why Liferay is putting together the Community Security Team to help address them.

Also we use OpenAM in our environment. The OpenAM Apache Web Server Policy Agent prevents any access to Liferay unless the user has a valid session with OpenAM.

Completely agree with you. Being in this business for over 12 years I got used to slipping dates. And there is always a good reason for that - after all, no one is consciously rising own customers' irritation.

As for the quality, the way I see it is : - if you go with CE then you have to know you are on your own and be prepared to fix issues by yourself and apply own patches . You can not relay on the next release as even if it was released on time, there is no guarantee it will contain the patch you are interested in. Even if there was a release every month or week it still can happen that the fix you are waiting for is not released for a few months. - if you go with EE then it's not because it's out of the box far more stable or reliable. It's the support which makes you feel more comfortable having regular patches and Liferay team resolving issues important for you in acceptable time.

Having this said I think Liferay could do better in communication and community support for those that decided to go with CE. Judging from what James wrote, it seams Liferay is well aware of that and I really look forward to see these improvements coming. I'll would also suggest to think about:

- how to help CE users fix things by themselves. I'm personally spending a lot of time monitoring all kinds of blogs, forums, security sites, social networks, ... for everything related to Liferay. Then if there is something that may have an impact on my portals (mostly security, performance and stability issues) it takes even more time to investigate and fix. Take for example this one http://issues.liferay.com/browse/LPS-18364. It turned out it's trivial to fix but it cost me almost a week of digging into Liferay's code back in March. So may be there should be some dedicated place where one can subscribe for and send alerts/notifications about potentially important issues. Then discuss workarounds and/or possible fixes. Perhaps this will also show what bug are important (I personally don't have the feeling voting in Jira is well known and widely used for this purpose). May be this should be another community program so only those who are interested can participate.

- how to improve the way community patches/contributions can make it into the next release. To see what I mean go to http://issues.liferay.com and run the following query:

1status = "Contributed Solution" AND resolution = Unresolved

Currently there are 114 unresolved issues (74 of them are bugs) for which someone has contributed a solution. As "Updated" column states the last activity on 2/3 of them was back in 2008-2011 period. For 6.1 version alone:

there are 14 contributed solutions and the most recent activity on them was over two weeks ago.

My point is, if you are using CE and fixing things for yourself anyway, then it make sense to contribute it back. Only there has to be clear procedure to guarantee (given you have followed the Liferay's development rules and conventions) your patch will make it into the next release and thus you don't have to maintain and adapt your own patches after next upgrade.

My point is, if you are using CE and fixing things for yourself anyway, then it make sense to contribute it back. Only there has to be clear procedure to guarantee (given you have followed the Liferay's development rules and conventions) your patch will make it into the next release

Indeed this is a major problem. In my experience tickets without a patch attached actually get dealt with sooner than tickets that don't. And unless your patch is a 1 line fix, often "smart" liferay developers ignore your patch, and roll their own. usually poorly so that you have to leave comments explaining why their fix is incorrect etc.

But many tickets are just not looked at. It's an incredibly frustrating affair. Take for instance LPS-22287 I supply steps to reproduce, i provide a minimal test case that proofs that the bug exists, and i hand them the solution on a silver platter. What more can i possibly do ?

Liferay employees like to talk about how liferay's opensource nature encourages the community to provide patches and make it a better product. As far as i am concerned it's all empty rhetoric. The only patches that are looked at are those that are logged by partners and those that are logged by Liferay pets like Drew Blessing

The way Liferay "solves" issues can really be frustrating. Sometimes a ticket doesn't seem to get recognized at all then after a while it's closed as "not reproducible". They wait as long as possible and then someone has fixed it somehow in the current trunk. But as you've reported the issue it occurred in the mentioned version so a "not reprocucible in trunk" is not a solution.

As an example take a look at the following issue (LPS-26327). It was not reported by me but I found out a workaround and by the comments it's working for other users too. But it's "not reproducible" lol. Another example: LPS-23636. The last example is a ticket which got reopened but since then there is no visible activity: LPS-25186.

Another point is the release cycle. As a developer I totally understand that milestones/ deadlines are set optimistically and not set in stone but if I remember right it's the third delay since march . Some of the bugfixes committed until now are critical for a production environment (e.g. website templates overrides existing pages or special characters are not saved properly into the db....) so a shorter release cycle (or more info in case you will miss a goal) would definetely be welcome.

And unless your patch is a 1 line fix, often "smart" liferay developers ignore your patch, and roll their own. usually poorly so that you have to leave comments explaining why their fix is incorrect etc....The only patches that are looked at are those that are logged by partners and those that are logged by Liferay pets like Drew Blessing

Please let's avoid bringing the discussion down to who is smarter, more knowledgeable or simply better understands the product. To be honest, if I was managing my own product of this scale having rapidly growing community and more and more people supplying patches I would probably run into similar issues. It costs a lot of time to examine someone's code and try to follow and understand his logic. Moreover the provided patch may fix the issue but introduce a different one (or simply does not work in some rarely used setups - for example multiple liferay instances with remote staging on WebSphere connected to DB2). No one would blindly apply a patch coming from a person that is not "trusted". So it makes perfect sens that patches coming form trusted community members and/or partners are more likely do be applied. And may be this is the key. May be such "trusted" developers should be involved in the process and allowed to evaluate and eventually mark patches supplied by other community members as "community verified". Then perhaps Liferay team can "safely" take them into considerations for the next release.

Not sure this is the perfect way to be organized but it's an idea. The bottom line is, lets quit complaining about Liferay guys doing this and not doing that and try to come up with a solution. If there is a cost-effective way Liferay can make use of community contributions and as result release more fixes more often, then I don't see a reason why they wouldn't do so. Am I right James?

Oliver Bayer:

Sometimes a ticket doesn't seem to get recognized at all then after a while it's closed as "not reproducible". They wait as long as possible and then someone has fixed it somehow in the current trunk. But as you've reported the issue it occurred in the mentioned version so a "not reprocucible in trunk" is not a solution.

Well, if it's "not reproducible in trunk" then it's fixed. I don't really care if they used my patch or not (I do NOT scan the credits for my name). May be my patch wasn't good enough, or may be it was a side effect of fixing different bug or implementing new feature, or may be someone was already working on it , or .... Does it matter? What matters for me is that I don't have to maintain my own patch as soon as I upgrade to the latest version.Sure communication can be improved (it can always be) but the main problem are issues for which community has provided fixes and even though they don't make it into the next release.

Please let's avoid bringing the discussion down to who is smarter, more knowledgeable or simply better understands the product. To be honest, if I was managing my own product of this scale having rapidly growing community and more and more people supplying patches I would probably run into similar issues. It costs a lot of time to examine someone's code and try to follow and understand his logic. Moreover the provided patch may fix the issue but introduce a different one (or simply does not work in some rarely used setups - for example multiple liferay instances with remote staging on WebSphere connected to DB2). No one would blindly apply a patch coming from a person that is not "trusted".

You missed the point completely. I think it was actually a core liferay dev (oh the irony) that tweeted a link to this presentation once. You should read it

Please let's avoid bringing the discussion down to who is smarter, more knowledgeable or simply better understands the product. To be honest, if I was managing my own product of this scale having rapidly growing community and more and more people supplying patches I would probably run into similar issues. It costs a lot of time to examine someone's code and try to follow and understand his logic. Moreover the provided patch may fix the issue but introduce a different one (or simply does not work in some rarely used setups - for example multiple liferay instances with remote staging on WebSphere connected to DB2). No one would blindly apply a patch coming from a person that is not "trusted".

You missed the point completely. I think it was actually a core liferay dev (oh the irony) that tweeted a link to this presentation once. You should read it

Thank you for the link. Yes I know this presentation and completely agree with it. But I think actually you are the one missing the point.

When my kids give me a drawing like the one in the presentation I am positively surprised, happy, grateful and proud of them. That doesn't mean I put that drawing into my porfolio right away or offer it to my customers. Besides, I don't thing anyone here is complaining about being badly treated by Liferay staff. I think the problem is that, so far, Liferay has been unable to - quickly release patches/versions fixing important security/performance/stability issues for CE and- make the best use of the help community offers.

So again, we can only complain about being ignored OR we can try to point out there is a room to improve and suggest a way. The second is what I'm trying to do.

Most definitely not. If you want to foster a community, you should help people write the code you want them to write. Not say "this sucks, i can do a better job" throw away the patch and do it yourself. Whether they then do a better or worse job is besides the point. You where arguing that It "costs a lot of time to examine someone's code and try to follow and understand his logic" so therefore it is ok to throw someone's "i luv you daddy drawing" out the window

Well, if it's "not reproducible in trunk" then it's fixed. I don't really care if they used my patch or not (I do NOT scan the credits for my name). May be my patch wasn't good enough, or may be it was a side effect of fixing different bug or implementing new feature, or may be someone was already working on it , or .... Does it matter? What matters for me is that I don't have to maintain my own patch as soon as I upgrade to the latest version.Sure communication can be improved (it can always be) but the main problem are issues for which community has provided fixes and even though they don't make it into the next release.

I don't want to read my name in the commit, who reads commit messages ? Me not. What I was trying to say is that it's nice if a bug is fixed in trunk but who cares? It's an exaggeration I know because it's great that it's fixed but..... If I'm reporting a bug for a given version e.g. 6.1. it's not useful if the answer is "not reproducible and/or fixed in trunk". I don't have a problem to fix my CE version on my own but not all bugfixes from trunk can be easily integrated into the current version. So there are many important bugfixes but the release of the new version is delayed three times in a row without any info.

I'm not bashing Liferay at all - it's only constructive criticism!! Otherwise would I take my time to participate at the forum or with filling jira tickets that much?

I started to look into Liferay approx. 1 1/2 years ago and followed the product evolution and it's community for some time now in a very passive way because I had hopes that I could use Liferay for a business idea I had. The business idea died (this had nothing to do with Liferay). I thought, wow Liferay has a cool product with quite some potential.

3 months back I installed the new version on my laptop and started to play around with it to work on another idea I am having. I got stuck with several problems, which I was partly able to overcome. I am also waiting for the GA2 release to appear for security and bug fixing reasons. Seeing the evolution which the product took I start to believe that some of the people from Liferay need to become more professional if the product shall succeed in the long run since otherwise the community which you highly praise will turn away at some stage and then you will be simply left competing with the big guys (IBM and Oracle).

I would suggest to look into the following (some things have been already suggested by others in one or the other way and some of them are being looked at):

Understandget a clear understanding of the community you are serving and you want to serve; consider their expectations and put it in balance with your business strategy

Be concrete and clear in the communicationCommunicate prominently (and not somewhere in a forum thread) if you walk the talk. If not, then don't be surprised if people get frustrated and turn away.What can be expected by a CE release and what cannot (expectation management)time lines (eg. there have been talks for some time in the forum regarding fixes for security issues and that this is being looked at)

ReleasesDon't overload a release: just put on the plate what you can eat. You still can show the menu which someday will be servedIf you stick to a release date then you will be able to plan according to that and keep the scope more variable. So ask yourself: what is more important: scope or timeline? And for whom is it more important?Do the most important things first and not the nicest ones.Why don't you use: Alpha, Beta RCn as the rest of the world does? Technical people know that a beta is not stable, but who knows that 6.1 GA1 is not production ready? Also most people would assume that 6.1 would be more stable than 6.0. On top the 6.1 is the default release you display.

DocumentationImprove the documentation in order to ease the frustration for new users.

Please don't get me wrong: I mean this criticism in a constructive way.

Most definitely not. If you want to foster a community, you should help people write the code you want them to write. Not say "this sucks, i can do a better job" throw away the patch and do it yourself.

Same here. I've completely given up on them but in my case it was encoding issues and localization issues. People who live in an island with one traffic light is not going to understand about highway and other traffic signs found in cities. That said, I think they're doing alright within their domain.

It may be better to setup another github site where community members can submit patches for other community members. This is liferay.com site and they are in business. They, also, seems to be doing very well so they are doing things "right" in their own perceptive.

But many tickets are just not looked at. It's an incredibly frustrating affair. Take for instance LPS-22287 I supply steps to reproduce, i provide a minimal test case that proofs that the bug exists, and i hand them the solution on a silver platter. What more can i possibly do ?

Well, you can try to look at from the point of view of liferay.com employee. I'm not sure how they are "awarded", but it may be based on how many bugs they fixes "themselves". So, they try to change the submitted patch so it'll be their own patch. If the issue seems to require too much time to fix, it's just easier to skip it. They are just employees doing their work. jira is part of liferay.com's work area and I think it should be treated separately from the community.

I was getting the impression from above there were stability concerns alongside the security ones which is why I specifically asked about stability issues since I haven't witnessed any stability problems myself.

If you mean "does liferay crash?", it doesn't. By "stability", I'm talking about does liferay do what it's suppose to do? No, it doesn't. There's more bugs introduced in 6.1.0 that was working properly in the earlier version. (it's been degraded from the previous version)

Degrade introduced by the following security issue is inexecusable. I'm not sure how that passed the test before the release was released.http://issues.liferay.com/browse/LPS-24888

Having this said I think Liferay could do better in communication and community support for those that decided to go with CE. Judging from what James wrote, it seams Liferay is well aware of that and I really look forward to see these improvements coming. I'll would also suggest to think about:

- how to help CE users fix things by themselves. I'm personally spending a lot of time monitoring all kinds of blogs, forums, security sites, social networks, ... for everything related to Liferay. Then if there is something that may have an impact on my portals (mostly security, performance and stability issues) it takes even more time to investigate and fix. Take for example this one http://issues.liferay.com/browse/LPS-18364. It turned out it's trivial to fix but it cost me almost a week of digging into Liferay's code back in March. So may be there should be some dedicated place where one can subscribe for and send alerts/notifications about potentially important issues. Then discuss workarounds and/or possible fixes. Perhaps this will also show what bug are important (I personally don't have the feeling voting in Jira is well known and widely used for this purpose). May be this should be another community program so only those who are interested can participate.

Yeah, I am *always* looking for ways to improve our community. I am 100% dedicated to our community and improving the experience (especially for newcomers).

One issue I see is that is that everyone thinks that "their" bugs are the most important, so if we had some kind of subscription thingy where anyone could "submit" an issue to be broadcasted to those subscribers, I don't think we'd get an objective assessment of all issues. But you can also subscribe to the JIRA feed and discuss workarounds/fixes in the comments for each issue. We could also create another forum specifically to discuss bugs, but I don't see how that would be much better than 'watching' (subscribing) to particular issues you are interested in. What kind of community program were you thinking?

- how to improve the way community patches/contributions can make it into the next release. To see what I mean go to http://issues.liferay.com and run the following query:

1status = "Contributed Solution" AND resolution = Unresolved

Currently there are 114 unresolved issues (74 of them are bugs) for which someone has contributed a solution. As "Updated" column states the last activity on 2/3 of them was back in 2008-2011 period. For 6.1 version alone:

there are 14 contributed solutions and the most recent activity on them was over two weeks ago.

My point is, if you are using CE and fixing things for yourself anyway, then it make sense to contribute it back. Only there has to be clear procedure to guarantee (given you have followed the Liferay's development rules and conventions) your patch will make it into the next release and thus you don't have to maintain and adapt your own patches after next upgrade.

And that would be my 2 cents.

Yes, this is a problem - we have been "dropping the ball" in recent times when it comes to shepherding open source contributions into the product. Last week I started going through all of these stale tickets, and found several that were not really open source contributions, but instead were really bug reports where the submitter didn't understand the meaning of the "Contribute Solution" button and clicked it. So once we get the community security team off the ground (I'm working on that this week) that's my next task - figure out what education and tuning of process is needed to fix the "ignored contributions" (and the related issue Jelmer points out - where contributions are ignored / silently reimplemented (sometimes incorrectly)).

And unless your patch is a 1 line fix, often "smart" liferay developers ignore your patch, and roll their own. usually poorly so that you have to leave comments explaining why their fix is incorrect etc....The only patches that are looked at are those that are logged by partners and those that are logged by Liferay pets like Drew Blessing

Please let's avoid bringing the discussion down to who is smarter, more knowledgeable or simply better understands the product. To be honest, if I was managing my own product of this scale having rapidly growing community and more and more people supplying patches I would probably run into similar issues. It costs a lot of time to examine someone's code and try to follow and understand his logic. Moreover the provided patch may fix the issue but introduce a different one (or simply does not work in some rarely used setups - for example multiple liferay instances with remote staging on WebSphere connected to DB2). No one would blindly apply a patch coming from a person that is not "trusted". So it makes perfect sens that patches coming form trusted community members and/or partners are more likely do be applied. And may be this is the key. May be such "trusted" developers should be involved in the process and allowed to evaluate and eventually mark patches supplied by other community members as "community verified". Then perhaps Liferay team can "safely" take them into considerations for the next release.

Not sure this is the perfect way to be organized but it's an idea. The bottom line is, lets quit complaining about Liferay guys doing this and not doing that and try to come up with a solution. If there is a cost-effective way Liferay can make use of community contributions and as result release more fixes more often, then I don't see a reason why they wouldn't do so. Am I right James?

This is the goal of the "Community Verifier" team - a team of "trusted" community members who have a proven track record of positive contributions in the community, know the code, and are able to objectively assess tickets for their validity and applicability to a specific release, and to filter out the "bad/wrong" tickets so that Liferay QA isn't bogged down by them and we in the community get a better/clearer/more accurate picture of the state of the union. Would you be interested in joining up?

Oliver Bayer:

Sometimes a ticket doesn't seem to get recognized at all then after a while it's closed as "not reproducible". They wait as long as possible and then someone has fixed it somehow in the current trunk. But as you've reported the issue it occurred in the mentioned version so a "not reprocucible in trunk" is not a solution.

Well, if it's "not reproducible in trunk" then it's fixed. I don't really care if they used my patch or not (I do NOT scan the credits for my name). May be my patch wasn't good enough, or may be it was a side effect of fixing different bug or implementing new feature, or may be someone was already working on it , or .... Does it matter? What matters for me is that I don't have to maintain my own patch as soon as I upgrade to the latest version.Sure communication can be improved (it can always be) but the main problem are issues for which community has provided fixes and even though they don't make it into the next release.

I agree with you that names/credit isn't important, but I also agree with Jelmer that sometimes (not always), developers do not communicate well (or at all!) with other developers who are making contributions, and we as a community need to constantly *want* to improve our collaboration skills. As with any human interaction, there's no "one answer" to "how" to best communicate with someone - but until you "know" someone, there needs to be a common set of "first responder" guidelines for all to use, as the initial contact between two people in the Liferay Community is typically under the same environment (i.e. online, through ticket comments/forum entries, etc).

But many tickets are just not looked at. It's an incredibly frustrating affair. Take for instance LPS-22287 I supply steps to reproduce, i provide a minimal test case that proofs that the bug exists, and i hand them the solution on a silver platter. What more can i possibly do ?

Well, you can try to look at from the point of view of liferay.com employee. I'm not sure how they are "awarded", but it may be based on how many bugs they fixes "themselves". So, they try to change the submitted patch so it'll be their own patch. If the issue seems to require too much time to fix, it's just easier to skip it. They are just employees doing their work. jira is part of liferay.com's work area and I think it should be treated separately from the community.

Again, I strongly disagree with your assertions and guesswork here - it is not based on how many bugs are fixed "themselves", and issues.liferay.com is our community issue tracker, not "just for" Liferay, Inc or a "work area" for liferay.com.

Again, I strongly disagree with your assertions and guesswork here - it is not based on how many bugs are fixed "themselves", and issues.liferay.com is our community issue tracker, not "just for" Liferay, Inc or a "work area" for liferay.com.

James, would you enlighten all of us about how issues are handled within liferay.com so I don't have to guesswork? I think most of us would be interested.

It seems it's just not me who is not completely satisfied with how issues are handled. Most of us are here just to pass some time away but have somebusiness related objectives as Drew pointed out in an earlier post. We've all invested some time to see a better software but it seems we are not completelysatisfied with the output from liferay.com in response to it. Business projects have a definite deadline - if liferay.com can not deliver on users' deadline, wejust have to go along without you.

Again, I strongly disagree with your assertions and guesswork here - it is not based on how many bugs are fixed "themselves", and issues.liferay.com is our community issue tracker, not "just for" Liferay, Inc or a "work area" for liferay.com.

James, would you enlighten all of us about how issues are handled within liferay.com so I don't have to guesswork? I think most of us would be interested.

I'm glad you asked! It's an excellent question. Internally, we have been going through some changes in the way we do development (you may have seen my recent post on development).

For all issues, whether created by Liferay staff or not, an initial evaluation of the ticket is done by the module maintainers/lead developer. This evaluation looks at the quality and impact of the bug: is it a duplicate? is it reproducible? is there enough information to understand the bug? Which releases are affected? is it a security vulnerability? Are there tons of votes or traffic on the forums related to the issue? Is it a regression from a previous release? For new features, does it have inherent functional value, and does it have business value in the market?. This evaluation leads to a priority based on what other tickets there are, and the current objectives for the next release, and the availability of resources. This results in a big, flat list of issues with priorities that are further refined/refactored by Liferay's program management office, where individual tickets are grouped into Epics and Stories, and placed in a backlog of sorts (but not a true backlog -- . Internally, developers are then tasked to these items. You know when a developer is working on an item when they assign it to themselves and set its status to "in progress". Until that time, currently the issues sit in the "Product Backlog" for issues that Liferay internal developers are planning on working on, or the "Community Backlog" for issues that are assigned to external developers. We try not to "bite off more than we can chew" and have checks in place to ensure that no developer is overloaded with tasks, using JIRA.

Some issues are small and don't really relate to a bigger picture item. For these, they typically fall into the "Quick Wins" category, where developers are free to take on these as their time allows.

In all cases, any effort already done for an issue is taken into account - we don't throw away or ignore contributions made on an issue. If further development of a community contribution is needed, the ticket is used as a primary collaboration area, but we also use forums, IRC, chat, etc. In some cases, the contributed code needs further refinement, or isn't quite correct, and I always encourage a dialog between developers to resolve this, rather than just "going it alone", but it happens (as Jelmer points out). I think we can do better as I've pointed out.

After an internal Liferay Developer fixes the bug, a round of peer review takes place with at least one other developer with expertise in the area (typically the component lead, but not always). Finally, once the developer and reviewer are satisfied, the issue is submitted to the project leads (e.g. for LPS, you can see who has done recent commits. For other projects (e.g. Liferay IDE), there are different project leads/committers). The developer leads serve as a final check before code is changed, and QA takes over to verify the fix from there (and the ticket is updated to reflect this progress through the workflow). In addition, for changes that impact release notes or documentation, the docs team or release team is notified.

I've glossed over a lot of details on how the various fields in JIRA are updated as tickets move through the workflow. If you have any specific questions, you can refer to the JIRA wiki page or ask, and I will update the JIRA pages to reflect the answer.

I've glossed over a lot of details on how the various fields in JIRA are updated as tickets move through the workflow. If you have any specific questions, you can refer to the JIRA wiki page or ask, and I will update the JIRA pages to reflect the answer.

One other thing I'd like to mention. Since last year, we switched to Github for source code management, and if you're interested in fixing a particular JIRA issue, submit your pull requests directly to the respective module maintainers, if you are comfortable with git. Once you've submitted the pull request, you should mark the JIRA issue as "Contributed Solution" using the existing process. The benefit of this is that collaboration on fixes can occur directly on the source in git, rather than through comments on a JIRA ticket. It results in a much faster resolution time for issues.

James, you really haven't answer the question. We're asking what Liferay.com can do to assist OUR project - not liferay.com's project. Most of here do have ongoing projects and have choosen to use liferay in them. We do want to have high quality system at a low price but we need it in a timely fashion because we do have a strict production date.Some of us have submitted patches to be incorporated only to find it was replaced with a "better solution" which doesn't work at all (do they really test their solutions?) Some of us have help debug liferay only to find that the fixed version isn't going to be ready for a very long period - after the release date of our project (Did you give Drew $200 dollars so he can buy subscriptioin license with it?). The new release even have several major regression bugs (we take people who created a regression bug off the project and send them to a remote office).

Forum here is a nice place to exchange information, but I really don't think liferay.com's jira and svn/github offers community members any real value to assist them in OUR own projects. If you disagree, please tell us how they can but before you do, I really would like to see a working version of a software that I can use right now in OUR projects.

Sorry again James. Liferay.com took too much time and I had several due projects which couldn't wait - I, now, already have my own source code repository which I'm operating from - it's more bug free. To most of us, it only requires few hours to set up a repository and fix bugs to meet our projects needs. It may be, Liferay.com maybe becoming too large and requiring more time to do some simple tasks.

James, you really haven't answer the question. We're asking what Liferay.com can do to assist OUR project - not liferay.com's project. Most of here do have ongoing projects and have choosen to use liferay in them. We do want to have high quality system at a low price but we need it in a timely fashion because we do have a strict production date.

We try to produce high quality, open source software that will benefit the community, by relying on the many contributors that constantly contribute and have a positive impact on our open source project. This is how we give back and assist your projects. It's a side benefit that we are able to use this for http://liferay.com .

I understand the need for a predictable schedule - I really do. Unfortunately, as I've said before, we aren't quite at a place where we can accurately predict when the release will be ready 6 months in advance, and I know it makes it hard to depend on the CE release schedule.

We try to stick to a yearly major CE release - as declared multiple times by multiple people, starting with 6.0. So 6.0 was released in September 2010, and 6.1 in January 2012 (it was not quite 1 year separation). So we try to maintain a regular cadence. We'll see where 6.2 lands.

Some of us have submitted patches to be incorporated only to find it was replaced with a "better solution" which doesn't work at all (do they really test their solutions?)

I already mentioned above that we can do better. This is NOT what happens most of the time.

Some of us have help debug liferay only to find that the fixed version isn't going to be ready for a very long period - after the release date of our project (Did you give Drew $200 dollars so he can buy subscriptioin license with it?). The new release even have several major regression bugs (we take people who created a regression bug off the project and send them to a remote office).

And at the same time, many others helped debug Liferay and were able to enjoy the fruits of their labors - in 6.0, 6.1, and in many releases prior to that, where bugs weren't present that would otherwise have been there. The community (including you) has been awesome in this regard! This GA2 release is a special case, and as I stated, we bit off more than we could chew and would ask for your patience and understanding for continually delaying the release. I think you will like the result.

Forum here is a nice place to exchange information, but I really don't think liferay.com's jira and svn/github offers community members any real value to assist them in OUR own projects. If you disagree, please tell us how they can but before you do, I really would like to see a working version of a software that I can use right now in OUR projects.

This GA2 release is a special case, and as I stated, we bit off more than we could chew and would ask for your patience and understanding for continually delaying the release. I think you will like the result.

I'm really not that interested in what will be, but more on what is. I don't work for a futures exchange. I need something I can use in project now. I think I say speak for most users here in the forum, but I'm really disappointed in the current situation - not just about GA2 but also about how bugs are handled.

I understand the need for a predictable schedule

BTW, we "predict" weather. We don't predict software project schedule. If liferay.com's projects are so unreliable thatusers have to "predict" what features will be included and when they are to be released, it's better not using it periodI think some of us has come to recognize this and have created their own source base.

I'm not trying to compete with Liferay.com, but Liferay.com is just not delivering what I need.

first I think that the situation isn't that bad that Liferay can't be used at all but I have to give Hitoshi credit: there are also a ton of bugs which made it into the GA1 release (and shouldn't have). I personally think there are the following two areas of improvement.

1. The way jira tickets are handled:A ticket shouldn't be closed without providing a patch or some hints to solve the issue (or at least a workaround till the new version is released). The famous "fixed in trunk" doesn't help us at all - nobody uses the trunk in a production system. What is even worse is if you have to wait that long to have the trunk becoming the new release version - which leads me to my next proposal.

2. The release cycle:There are 689 of 701 tickets resolved for the next GA release so the few remaining tickets should be fixed in a week ;). There shouldn't been any other commits if a GA release date is set. First releasing a new version and then working on new features in the trunk. I'm into jsf development too so I think MyFaces is a good example. Currently the 2.1 branch is stable. The newest release is 2.1.8 so there are 8 releases for the current iterration. You shouldn't have to wait for nearly thousand tickets to be fixed before releasing a new version (it's crystal clear that you have to much dependencies by such an amount of tickets). The better would be to release more often - of course with less bugs fixed.

I think most of us would be satisfied if liferay.com gave one year subscription if a person did xxxx amount of work in the community. The prizes are fun but it really doesn't do to much for a project in hand. I don't think people are competing too much for the top prize either. I think it would be more beneficial to the community if there are more people do certain amount to involvement rather than have few people do much of the work. I think more companies would be willing to allow their employers to do some amount of work in the community if they're able to get a free subscription.

first I think that the situation isn't that bad that Liferay can't be used at all but I have to give Hitoshi credit: there are also a ton of bugs which made it into the GA1 release (and shouldn't have). I personally think there are the following two areas of improvement.

1. The way jira tickets are handled:A ticket shouldn't be closed without providing a patch or some hints to solve the issue (or at least a workaround till the new version is released). The famous "fixed in trunk" doesn't help us at all - nobody uses the trunk in a production system. What is even worse is if you have to wait that long to have the trunk becoming the new release version - which leads me to my next proposal.

2. The release cycle:There are 689 of 701 tickets resolved for the next GA release so the few remaining tickets should be fixed in a week ;). There shouldn't been any other commits if a GA release date is set. First releasing a new version and then working on new features in the trunk. I'm into jsf development too so I think MyFaces is a good example. Currently the 2.1 branch is stable. The newest release is 2.1.8 so there are 8 releases for the current iterration. You shouldn't have to wait for nearly thousand tickets to be fixed before releasing a new version (it's crystal clear that you have to much dependencies by such an amount of tickets). The better would be to release more often - of course with less bugs fixed.

What do you think?

Regards Oli

I think this is a very good assessment of where we can improve, and I intend to work toward those goals. More frequent CE releases and better handling of issues. I'm going to let actions speak louder than words

I'm really not that interested in what will be, but more on what is. I don't work for a futures exchange. I need something I can use in project now. I think I say speak for most users here in the forum, but I'm really disappointed in the current situation - not just about GA2 but also about how bugs are handled.

It's threads like this and users like you that make Liferay great -- yes, we have things we can improve on, and I wholeheartedly believe we can do so. We can't fix the past, so I'm looking at ways we can improve in the future, with more predictability, better quality, and a community that works together and can be proud of its accomplishments. I hope that we do not lose you as a valuable contributor, but as I stated earlier, actions speak louder than words. I think we have identified the areas to improve on in this thread, so let's see if we can do that.

1. The way jira tickets are handled:A ticket shouldn't be closed without providing a patch or some hints to solve the issue (or at least a workaround till the new version is released). The famous "fixed in trunk" doesn't help us at all - nobody uses the trunk in a production system. What is even worse is if you have to wait that long to have the trunk becoming the new release version - which leads me to my next proposal.

The famous "fixed in trunk" is actually not that bad, since you usually have pull request assigned to the issue and can see what has changed and attempt to apply the fix yourself. That's why I wrote earlier that as long as it's fixed, I'm not complaining about how, where and by who. Of course the problem arises when the fix is too complex and/or you don't have enough knowledge in specific area of Liferay to apply it on older version of the code.So to sum it up, there are 3 situations where one needs help:

The problem you are dealing with is not yet fixed (perhaps even not yet reported)

The problem is fixed in trunk but you can't wait for the next version and it's too complex to apply the fix by yourself

The problem is fixed in newer version but you can't upgrade (for whatever reason)

That is what I had in mind by "help CE users fix things by themselves" in my prevois post. Theoretically, as James pointed out, we have all the tools in place (Jira, Forums, Wikis, ...). But for some reason it does not work all that well. For example, Hitoshi stated he has his own source code repository which he is operating from. I on the other hand, have a number of hooks/ext plug-ins fixig various issues in various Liferay versions. Have we fixed the same issues independently (and perhaps in different way)? Most likely - yes. Would it be more effective if we have joined forces? Probably. Then why we didn't? More over, why we even didn't know about each others fixes up until now? And I bet it's not only the two of us.

Number of people have suggested to "fork liferay" or as Hitoshi wrote about to "setup another github site where community members can submit patches for other community members". I would lie if I say I haven't been thinkig about it as well (just may be more in terms of "Liferay community patches" project). But is it worth doing? I may be naive but I still beleve Liferay staff do care about the community and they are only temporaly dealing with "grown too big too fast" sindrom. So instead of maintainig a separete repository wouldn't it be better to improve the way we, the comminuty, communicate about, rate and fix issues. Think about what Hitoshi suggested just without setting up another github site. Then perhaps, reorganize the priorities of Community Verifier program so issues with contributed solutions are taken care first. Finally we may eventually get Liferay to guarantee that once issue is verified it's going to make it into the next release.

This is the goal of the "Community Verifier" team - a team of "trusted" community members who have a proven track record of positive contributions in the community, know the code, and are able to objectively assess tickets for their validity and applicability to a specific release, and to filter out the "bad/wrong" tickets so that Liferay QA isn't bogged down by them and we in the community get a better/clearer/more accurate picture of the state of the union. Would you be interested in joining up?

The reason I didn't apply back when the program started was that I felt I wouldn't be able to spend enough time on the subject to be able to add some value. Now I'm willing to try if my contributions can qualify for "proven track record of positive contributions in the community"

I really like the way Gregory is handling the Liferay IDE project. He's providing us with enough information and opportunities to test out new features. Liferay IDE is becoming very stable functionalities wise and quality-wise with each release.

Example of good information:http://www.liferay.com/web/gregory.amerson/blog?p_p_id=33&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&_33_struts_action=%2Fblogs%2Fview

Gregory is telling us that we may be getting errors and that's he's going to fix it and things we can do while it's being fixed. I can be sure Liferay Studio is ready for the enterprise by looking at Liferay IDE project. Unfortunately, I'm very certain that Liferay EE is NOT nowhere near ready for a real enterprise - I had to develop my own Enterprise version so that I can use liferay in production environment.

Now I'm willing to try if my contributions can qualify for "proven track record of positive contributions in the community"

I think Drew, who contributed the most would say the same thing. I really haven't gotten any "positive" feedback from involvement in the verifier team because I really don't know how my contributions have ended up - I don't have any software yet which was a result of my contribution.

I feel that I've wasted hours of my time on "just for fun community project". As such, unless you have time to waste, involvement in such projects isn't really doing any positive contribution to the community - maybe to liferay.com, but nothing to the community.

The famous "fixed in trunk" is actually not that bad, since you usually have pull request assigned to the issue and can see what has changed and attempt to apply the fix yourself. That's why I wrote earlier that as long as it's fixed, I'm not complaining about how, where and by who. Of course the problem arises when the fix is too complex and/or you don't have enough knowledge in specific area of Liferay to apply it on older version of the code.So to sum it up, there are 3 situations where one needs help:

The problem you are dealing with is not yet fixed (perhaps even not yet reported)

The problem is fixed in trunk but you can't wait for the next version and it's too complex to apply the fix by yourself

The problem is fixed in newer version but you can't upgrade (for whatever reason)

That is what I had in mind by "help CE users fix things by themselves" in my prevois post. Theoretically, as James pointed out, we have all the tools in place (Jira, Forums, Wikis, ...). But for some reason it does not work all that well. For example, Hitoshi stated he has his own source code repository which he is operating from. I on the other hand, have a number of hooks/ext plug-ins fixig various issues in various Liferay versions. Have we fixed the same issues independently (and perhaps in different way)? Most likely - yes. Would it be more effective if we have joined forces? Probably. Then why we didn't? More over, why we even didn't know about each others fixes up until now? And I bet it's not only the two of us.

Number of people have suggested to "fork liferay" or as Hitoshi wrote about to "setup another github site where community members can submit patches for other community members". I would lie if I say I haven't been thinkig about it as well (just may be more in terms of "Liferay community patches" project). But is it worth doing? I may be naive but I still beleve Liferay staff do care about the community and they are only temporaly dealing with "grown too big too fast" sindrom. So instead of maintainig a separete repository wouldn't it be better to improve the way we, the comminuty, communicate about, rate and fix issues. Think about what Hitoshi suggested just without setting up another github site. Then perhaps, reorganize the priorities of Community Verifier program so issues with contributed solutions are taken care first. Finally we may eventually get Liferay to guarantee that once issue is verified it's going to make it into the next release.

Milen,

I think you made some excellent points and have great ideas. James is currently setting up a community team that is going to "backport" patches to CE. This should alleviate many issues where you, or other administrators, must know how or have time to apply the particular fixes to your installation. As far as I know this team will be producing both source code and binary updates. I don't know the full specifics of the program but I think we'll be pleasantly surprised.

On your comments about the community verifier team, I wonder if your suggestion may be helpful. I actually started going through the contributed solution tickets last week. Some were old and had already been addressed via other methods. Some are indeed waiting for attention and I think that's exactly what the CV team can help with.

Hitoshi Ozawa:

I think Drew, who contributed the most would say the same thing. I really haven't gotten any "positive" feedback from involvement in the verifier team because I really don't know how my contributions have ended up - I don't have any software yet which was a result of my contribution.

Hitoshi,

Quite contrary, I feel that my contributions in the CV team are well worth it. Every ticket that I verified I clicked the "watch" button and received every update that the Liferay team made. I am happy to say that most of them have been addressed and are now closed.

I also feel that my code contributions have been well received. I make sure to submit the Github pull request to the appropriate person as James suggested. I also use Twitter to draw attention to the issue/improvement I am writing code for. I think the CV team can help to draw attention to these types of issues, too. At the very least, the team may be able to look at the submitted patch and see if the pull request is submitted correctly, etc. Basically, make sure the ducks are in a row so that when a Liferay developer comes along they have everything in order and can quickly go to work reviewing and committing the patch.

In all, some excellent points have been made in this thread. James has satisfactorily answered all the questions I have and I know things are not going to change overnight. However, I know that the Liferay team is taking our criticism and suggestions to heart and they do care. We will see good things come from this thread. All we can do now is have faith.

Drew, you can "see it", but do you have a software with resolved solution in your hands? It doesn't do me any good to just see status wording change on my screen. I need resolution in my hands. If the community is finding and fixing bugs, shouldn't they be entitled to get the patch for those first-hand too? It only seems fair.

All we can do now is have faith.

Well, He hasn't let me down, but I don't think He'll be able to resolve these minor issues in our lives.

If the community is finding and fixing bugs, shouldn't they be entitled to get the patch for those first-hand too?

Absolutely! If all you need is a patch, then just grab the commit from the GitHub repo. You can clone the entire repo, then checkout the particular commit that the issue was fixed on. All issues that are marked as resolved have a commit ID attached.

Yes, but aren't those patches based on the current "trunk" (development source code) instead of the last stable release?

I'm not speaking just for myself here, but I wonder how many users would actually be able to use these "patches" as the way they are now.

Just wants everybody to be able to reap the fruits of their labor. :-)

Each fix gets committed to both the 6.1.x and 6.2.x branches. The 6.1.x branch is the latest 6.1 development code but represents what will become the next stable 6.1 release. I'm betting 90% of the fixes would apply cleanly to the existing stable branch. Only ones requiring extensive changes and ones that overlap with additional changes in the 6.1.x branch would not apply cleanly. Whatever the case, many of these things should be addressed by the forthcoming community security team which James has explained briefly above. I'll be interested to see what this team can do and how it impacts things like this.

I'm bringing this up because there were several posts about not being applying corrections to the 6.1.0 CE and users didn't know too much about programming.As of now, I think there are many users counting on Juan to roll up a patch to fixed issues.

Really, I think what it comes down to is consistent releases and not falling into the trap of "biting off more than you can chew". Smaller more timely releases would be much appreciated. Also, Finding a better way to reward people like Hitoshi for the code contributions and thousands of forum posts. Seriously...Liferay should put him on the payroll with how many people he's helped out in these forums.

I am thinking more along the lines of backporting fixes to the community edition and doing regular releases. Patches are all nice and dandy but most people just want to be able to download a zip file that works.

I had exactly the same idea - the infrastructure started working several days ago, now it is internally tested.To offer this to the general public I'd like to check legal first.

GA2 has been messed up a month ago when suddenly a "Merge a bunch of fixes and tests" was done to 6.1.x Github.

Even though one reports issues for 6.1.x GA2 they just sit there because the 6.2.x and EE ones have to be fixed first.

Each fix gets committed to both the 6.1.x and 6.2.x branches.

This happened when there were only a few differences between 6.1.x and 6.2.x. Now things are different 6.2.x has considerably changed and I dont expect a 6.2.x fix to be compatible with 6.1.x any longer.

This is a 6.1.x GA2 testing one I posted the 12 of July. http://issues.liferay.com/browse/LPS-28361 Still sitting there and probably not even looked at. Not being able to modify templates on the run looks like a severe issue to me, maybe wrong, but only a few days from expected release. Mmmmh.

Oh... and there are many others just not taken in consideration. Many that just need to be closed because somehow fixed while doing some other stuff or simply enough not being bugs at all. Yes one of these is mine... http://issues.liferay.com/browse/LPS-27584 Dated 28th of may, sitll there.

Whats happened to community verifiers???

GA1 as often repeated in this thread is unusable not unstable... Sadly enough, GA2 is taking the same road.... At least until today...

GA2 has been messed up a month ago when suddenly a "Merge a bunch of fixes and tests" was done to 6.1.x Github.

Even though one reports issues for 6.1.x GA2 they just sit there because the 6.2.x and EE ones have to be fixed first.

I don't agree at all. In fact, right now all fixes (that affects 6.1.1) are being backported to 6.1.x too.

Davide Rossi:

This happened when there were only a few differences between 6.1.x and 6.2.x. Now things are different 6.2.x has considerably changed and I dont expect a 6.2.x fix to be compatible with 6.1.x any longer.

Why do you think that? After that commit you said ("Merge a bunch of fixes...") 6.2 and 6.1 are much similar than before.

Davide Rossi:

This is a 6.1.x GA2 testing one I posted the 12 of July. http://issues.liferay.com/browse/LPS-28361 Still sitting there and probably not even looked at. Not being able to modify templates on the run looks like a severe issue to me, maybe wrong, but only a few days from expected release. Mmmmh.

I've just pushed that issue so Liferay staff can take a look at it, hopefully someone can backport the fix to 6.1.x.

Davide Rossi:

Whats happened to community verifiers???

James Falkner can answer this question better than me, but AFAIK this program was only for some time, and doesn't last forever.

Davide Rossi:

GA1 as often repeated in this thread is unusable not unstable... Sadly enough, GA2 is taking the same road.... At least until today...

Poor Community....

Don't agree. IMHO this version is quite stable and a "bunch" of fixes had been solved and backported. In last weeks many changes are being done to source so perhaps some bugs are being added, but even with that all is being fixed very quickly.

Hi Juan,You probably see things I don't see from the outside and I'll treasure your comments.

Thanks for having brought LPS-28361 to attention.It was just closed because a duplicate of LPS-28479 reported for: Liferay Portal 6.1.10 EE GA1 and will be fixed on, as stated in LPS: Fix Version/s: 6.2.X, --Sprint 6/12.It works in 6.2.X. No need to fix there. May be alot of confusion by my part, but certainly not clear.

Just to be precise, I am not saying work is not being done and the quantity? Playing arround with 6.2.X, is increadible. I also understand the ammount of work that has taken place to get marketplace to grounds. Community wise things are changing continuously and I believe more will come making things easier and better, but until today things have been hard on CE versions. This has not changed as fast as the rest.

Indeed -- the JIRA date has been set to Monday (i.e. in 48-71.9999 hours), which is what we're shooting for! So, shouldn't be long now. Thanks for your continued patience. It should be an interesting ride.

Is there a developer mailing list? Maybe that could be a good way to keep people informed on security issues etc. that need attention? ..and make the development more see through, or at least allow community communicate efficiently on things that matter.

And also it has some barrier of admission so maybe it wouldn't get so bloated with disinformation immediately (as some one already suggested). I find using these forums as information source as contributing to fragmentation of developer life (also my life).

If there are already some streams of important information excisting please point them out. Like rss-feeds are another happiness inducing ways of communicating. Or just plain twitter for announcments. The jira is way too unfiltered right now, or then I'm just stupid, which may be the case too.

..and while I'm getting into ranting, what's with the blogs? Does there need to be gazillion blogs for different people inside liferay, they could also be filttered and arranged somehow?

Hi NIko You raise a number of good points IMHO regarding information flows and filters.I have been pushing (well not recently as I gave up) for user groups on liferay.com to be exploited for things like training course attendees (eg developers advanced developers, theme design, admin) etc. which may go towards your idea of mailing lists - easy to then email the user group if you have to. I wouldn't see them as restricted but initially it was as a way to continue the interaction attendees get during 2-3 days of intense coding.The whole user group functionality is something that either needs addressing in the core or just how liferay.com implements things. I agree about the blogs from liferay staff but don't want to really stop that source of information either.

Meanwhile it is now the 31st! Will GA2 be out before August anywhere (Alaska perhaps?).

So, did you just raise the proiorty of issue to get it fixed? Community verifiers is about community members like you and me changing the priority of issues to get what we want get processed by liferay.com.

Meanwhile it is now the 31st! Will GA2 be out before August anywhere (Alaska perhaps?).

Well, GA2 is finally out,but I think liferay is going to go way down in Gartner's positional matrix this year because of this - they can't deliver what they promised. It's a pity because they have been doing very good until this year.

Well, GA2 is finally out,but I think liferay is going to go way down in Gartner's positional matrix this year because of this - they can't deliver what they promised. It's a pity because they have been doing very good until this year.

Well, they told us GA2 was going to be out earlier this Spring. If I order a pizza and it's delivered half a year afterward, I call that bad delivery service. This doesn't mean the pizza tastes bad but just late.Software development is not just about functionality, it's a combination of functionality, schedule, and cost.

Community verifiers is about community members like you and me changing the priority of issues to get what we want get processed by liferay.com.

I don't think that's the intention of CV at all. It could possibly be used in that way but if anyone is doing that as a primary goal they are totally missing the point.

Shortly I will be posting a proposal for CV to reform and re-strategize so we can get going. Specifically, I'd like to focus on community contributions and narrowing the gap between community members/developers, and Liferay core developers.

I can not install additional plugins1. ant deploy ignored2. from the admin panel removed the option "Install additional plug-ins"

Are you certain everything is set up correctly in your environment? I set up Liferay IDE 1.6 using the 6.1.1 GA2 SDK and Liferay Portal 6.1.1 GA2 today and plugins deployed fine. I deployed using ant and also dropped WARs directly into the deploy directory.

Tell me more about your environment and how you set up the new SDK and portal. Hopefully we can help you troubleshoot the issue.

I don't think that's the intention of CV at all. It could possibly be used in that way but if anyone is doing that as a primary goal they are totally missing the point.

The gist of my reply is to say that it's not the problem with CV not working because a user submitted an issue and it hasn't been processed the way he wanted it to be processes. If he has a complaint about how an issue is processed, he should join the CV and follow his issue through himself.

I think the original intent of CV has to give community members (non-liferay.com members) an opportunity to voice more on how issues are processed. There's no fee and there's actually no commitment to do any work. More users should be taking this opportunity if they feel issues are not being satisfactory fulfilled.

The gist of my reply is to say that it's not the problem with CV not working because a user submitted an issue and it hasn't been processed the way he wanted it to be processes. If he has a complaint about how an issue is processed, he should join the CV and follow his issue through himself.

I think the original intent of CV has to give community members (non-liferay.com members) an opportunity to voice more on how issues are processed. There's no fee and there's actually no commitment to do any work. More users should be taking this opportunity if they feel issues are not being satisfactory fulfilled.

I can not install additional plugins1. ant deploy ignored2. from the admin panel removed the option "Install additional plug-ins"

Are you certain everything is set up correctly in your environment? I set up Liferay IDE 1.6 using the 6.1.1 GA2 SDK and Liferay Portal 6.1.1 GA2 today and plugins deployed fine. I deployed using ant and also dropped WARs directly into the deploy directory.

Tell me more about your environment and how you set up the new SDK and portal. Hopefully we can help you troubleshoot the issue.

everything is fine. I updated the wrong portal, has changed the absolute path. a directory deploy retained the old way

I can not install additional plugins1. ant deploy ignored2. from the admin panel removed the option "Install additional plug-ins"

Are you certain everything is set up correctly in your environment? I set up Liferay IDE 1.6 using the 6.1.1 GA2 SDK and Liferay Portal 6.1.1 GA2 today and plugins deployed fine. I deployed using ant and also dropped WARs directly into the deploy directory.

Tell me more about your environment and how you set up the new SDK and portal. Hopefully we can help you troubleshoot the issue.

everything is fine. I updated the wrong portal, has changed the absolute path. a directory deploy retained the old way

Next time, can you create a new thread if you have a question not directly related to the topic of this thread. You question is more about using GA2 than about GA2 release schedule. The thread gets confusing and out of focus when people starts posting different questions in a thread.

Well, they told us GA2 was going to be out earlier this Spring. If I order a pizza and it's delivered half a year afterward, I call that bad delivery service. This doesn't mean the pizza tastes bad but just late.Software development is not just about functionality, it's a combination of functionality, schedule, and cost.

I'm planning to set up a service to "fill this gap". Right now we are working out the details how to involve the community in the appropriate way. For me the biggest problem is how to accept patches in a reliable but rapid way - at the end of the day this is a "security sensitive" product, patches just cannot be added without a closer look. I'm thinking now of a "social equity - weighted voting" method. Must be mostly automated - this should be a free service and we don't have too much human resource for that.