Forums

Home » Liferay Portal » English » 3. Development

Combination View Flat View Tree View
Threads [ Previous | Next ]
Showing 41 - 60 of 107 results.
of 6
Jamie L Sammons
RE: GA2 Release
June 20, 2012 9:19 AM
Answer

Jamie L Sammons

Rank: Junior Member

Posts: 33

Join Date: November 18, 2008

Recent Posts

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.

-Jamie
Linus Sphinx
RE: GA2 Release
June 20, 2012 1:42 PM
Answer

Linus Sphinx

Rank: Junior Member

Posts: 84

Join Date: August 12, 2010

Recent Posts

Good luck with that, it's the enemy within you should be most concerned about in 2012.
Milen Dyankov
RE: GA2 Release
June 21, 2012 1:41 AM
Answer

Milen Dyankov

Rank: Regular Member

Posts: 173

Join Date: September 23, 2009

Recent Posts

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:
1status = "Contributed Solution" AND resolution = Unresolved and affectedVersion in ("6.1.0  CE GA1", "6.1.0 CE RC1", "6.1.0 GA1", "6.1.10 EE1")

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.
Jelmer Kuperus
RE: GA2 Release
June 22, 2012 4:12 AM
Answer

Jelmer Kuperus

Rank: Liferay Legend

Posts: 1192

Join Date: March 10, 2010

Recent Posts

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
Oliver Bayer
RE: GA2 Release
June 22, 2012 5:13 AM
Answer

Oliver Bayer

Rank: Liferay Master

Posts: 875

Join Date: February 18, 2009

Recent Posts

Hi Jelmer,

you're totally right!!

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 emoticon. 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.

Greets Oli
Milen Dyankov
RE: GA2 Release
June 22, 2012 7:12 AM
Answer

Milen Dyankov

Rank: Regular Member

Posts: 173

Join Date: September 23, 2009

Recent Posts

There are 2 comments I need to disagree with:

jelmer kuperus:
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.
Jelmer Kuperus
RE: GA2 Release
June 22, 2012 8:34 AM
Answer

Jelmer Kuperus

Rank: Liferay Legend

Posts: 1192

Join Date: March 10, 2010

Recent Posts

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
Milen Dyankov
RE: GA2 Release
June 22, 2012 9:06 AM
Answer

Milen Dyankov

Rank: Regular Member

Posts: 173

Join Date: September 23, 2009

Recent Posts

jelmer kuperus:
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.
Jelmer Kuperus
RE: GA2 Release
June 23, 2012 2:53 AM
Answer

Jelmer Kuperus

Rank: Liferay Legend

Posts: 1192

Join Date: March 10, 2010

Recent Posts

But I think actually you are the one missing the point.


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

You are wrong
Oliver Bayer
RE: GA2 Release
June 22, 2012 10:45 AM
Answer

Oliver Bayer

Rank: Liferay Master

Posts: 875

Join Date: February 18, 2009

Recent Posts

Hi Milen,

thanks for the reply but I think you're missing my point too.


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 emoticon? 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?

Greets Oli
Stephan Schoenberger
RE: GA2 Release
June 23, 2012 2:29 AM
Answer

Stephan Schoenberger

Rank: New Member

Posts: 1

Join Date: April 7, 2012

Recent Posts

Hi James,

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):

Understand
get 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 communication
Communicate 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)

Releases
Don't overload a release: just put on the plate what you can eat. You still can show the menu which someday will be served
If 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.

Documentation
Improve 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.

Kind regards,
Stephan
Hitoshi Ozawa
RE: GA2 Release
June 23, 2012 7:30 AM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7990

Join Date: March 23, 2010

Recent Posts

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.
Hitoshi Ozawa
RE: GA2 Release
June 23, 2012 7:43 AM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7990

Join Date: March 23, 2010

Recent Posts

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.
Hitoshi Ozawa
RE: GA2 Release
June 24, 2012 2:48 PM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7990

Join Date: March 23, 2010

Recent Posts

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
James Falkner
RE: GA2 Release
June 25, 2012 6:23 AM
Answer

James Falkner

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1216

Join Date: September 17, 2010

Recent Posts

Milen Dyankov:

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:
1status = "Contributed Solution" AND resolution = Unresolved and affectedVersion in ("6.1.0  CE GA1", "6.1.0 CE RC1", "6.1.0 GA1", "6.1.10 EE1")

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)).
James Falkner
RE: GA2 Release
June 25, 2012 6:33 AM
Answer

James Falkner

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1216

Join Date: September 17, 2010

Recent Posts

Milen Dyankov:
There are 2 comments I need to disagree with:

jelmer kuperus:
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).
James Falkner
RE: GA2 Release
June 25, 2012 6:39 AM
Answer

James Falkner

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1216

Join Date: September 17, 2010

Recent Posts

Hitoshi Ozawa:
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.
Hitoshi Ozawa
RE: GA2 Release
June 25, 2012 4:12 PM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7990

Join Date: March 23, 2010

Recent Posts

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 some
business 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 completely
satisfied 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, we
just have to go along without you.
James Falkner
RE: GA2 Release
June 26, 2012 7:56 AM
Answer

James Falkner

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1216

Join Date: September 17, 2010

Recent Posts

Hitoshi Ozawa:
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.
James Falkner
RE: GA2 Release
June 26, 2012 8:58 AM
Answer

James Falkner

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1216

Join Date: September 17, 2010

Recent Posts

James Falkner:

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.
Showing 41 - 60 of 107 results.
of 6