Re: [cross-project-issues-dev] Kepler dates, IP Logs, and reviews
Hi Found it. It's lurking on the left of http://eclipse.org/projects/tools/ip_contribution_review.php, so if you ignore the rubbish from http://eclipse.org/projects/tools/ip_contribution_review.php you get the good old review. Regards Ed Willink On 17/05/2013 07:18, Ed Willink wrote: Hi What has happened to the old (very good) IP tool? It gave me a good auto-generated log for MDT/OCL that I could easily review. http://eclipse.org/projects/tools/ip_contribution_review.php is hard to find (no link from portal or project page) and gives me a list of over 600 bugs to review. No way. There have been zero IP contributions so I expect to do the job in 10 minutes not 10 hours. If there really is a change in diligence then please threshold it at resolution after Juno, since all pre-Juno bugs have been IP logged and approved. Regards Ed Willink On 26/04/2013 19:24, The Eclipse Foundation wrote: Kepler approaches. I'm starting to get IP Log review requests for the upcoming release. In at least two cases, I'm pretty sure that the submitter thought that the release date was in May. To be clear, here are the dates: May 24/2013 - Deadline to submit IP Logs for Kepler releases June 5/2013 - PMC-approved Review materials submitted to EMO June 12/2013 - Kepler Uber Release review June 26/2013 - Kepler release The IP Logs are not due for another month. It's still a little early, but it's perfectly acceptable to submit your IP log for review in advance of the actual required-by date. Just keep in mind that the log needs to accurately reflect the content that you're releasing; if you anticipate receiving any contributions from folks who are not committers, it might be a good idea to hold off for a while. While I'm at it, I'd like to make a plea to everybody to please try and honour the dates specified. There are a few projects that make a habit of submitting the required materials late; this causes a lot of stress for everybody involved. If you haven't started thinking about your IP Log and review documentation, now might be a good time to do so. I need to have you PMC-approved review documentation before EOB on June 5/2013. You can either do what we've been doing for years and submit this information as a presentation, document, PDF, or whatever. Or you can just enter review information directly in the release record in the Project Management Infrastructure. A few of you have already started doing the latter; my sense is that it is an easy way to assemble and provide this information. Please let me know if you think otherwise, or if there is anything that we can do to improve it. The PMC approval part is important. Get it approved. This may take some time. Plan to engage your PMC at least a full week in advance of the June 5 deadline. PMC members, please make sure that the document is complete and that you are satisfied with its content before providing your approval. When I look at the extremely short (or non-existent) "outside contributions" sections on some IP logs, I grow concerned that some projects aren't doing enough to court the community and grow diversity. Please use the Release Review checklist to make sure that you've done all the necessary bits: http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews#Checklist Note that this checklist has been around for a long time. There should be nothing new or surprising here. I've noticed that a lot of projects do not have plans posted. This is an important and necessary part of the development process. Plan information can be entered directly in the release record in the Project Management Infrastructure. Providing a project plan in a standard format is required. Wrestling with XML is no longer required. It's easy. Please make this happen. Note that planning should happen at the beginning of a release cycle. PMCs, please impress the importance of this on your projects. Thanks, Wayne -- Wayne Beaton on behalf of the Eclipse Foundation ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org
Re: [cross-project-issues-dev] Kepler dates, IP Logs, and reviews
I opened a ticket some time ago, proposing to have the link on the project page: https://bugs.eclipse.org/bugs/show_bug.cgi?id=400551 I guess it will be then easy to find. Krum From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed Willink Sent: Freitag, 17. Mai 2013 08:26 To: Cross project issues Subject: Re: [cross-project-issues-dev] Kepler dates, IP Logs, and reviews Hi Found it. It's lurking on the left of http://eclipse.org/projects/tools/ip_contribution_review.php, so if you ignore the rubbish from http://eclipse.org/projects/tools/ip_contribution_review.php you get the good old review. Regards Ed Willink On 17/05/2013 07:18, Ed Willink wrote: Hi What has happened to the old (very good) IP tool? It gave me a good auto-generated log for MDT/OCL that I could easily review. http://eclipse.org/projects/tools/ip_contribution_review.php is hard to find (no link from portal or project page) and gives me a list of over 600 bugs to review. No way. There have been zero IP contributions so I expect to do the job in 10 minutes not 10 hours. If there really is a change in diligence then please threshold it at resolution after Juno, since all pre-Juno bugs have been IP logged and approved. Regards Ed Willink On 26/04/2013 19:24, The Eclipse Foundation wrote: Kepler approaches. I'm starting to get IP Log review requests for the upcoming release. In at least two cases, I'm pretty sure that the submitter thought that the release date was in May. To be clear, here are the dates: May 24/2013 - Deadline to submit IP Logs for Kepler releases June 5/2013 - PMC-approved Review materials submitted to EMO June 12/2013 - Kepler Uber Release review June 26/2013 - Kepler release The IP Logs are not due for another month. It's still a little early, but it's perfectly acceptable to submit your IP log for review in advance of the actual required-by date. Just keep in mind that the log needs to accurately reflect the content that you're releasing; if you anticipate receiving any contributions from folks who are not committers, it might be a good idea to hold off for a while. While I'm at it, I'd like to make a plea to everybody to please try and honour the dates specified. There are a few projects that make a habit of submitting the required materials late; this causes a lot of stress for everybody involved. If you haven't started thinking about your IP Log and review documentation, now might be a good time to do so. I need to have you PMC-approved review documentation before EOB on June 5/2013. You can either do what we've been doing for years and submit this information as a presentation, document, PDF, or whatever. Or you can just enter review information directly in the release record in the Project Management Infrastructure. A few of you have already started doing the latter; my sense is that it is an easy way to assemble and provide this information. Please let me know if you think otherwise, or if there is anything that we can do to improve it. The PMC approval part is important. Get it approved. This may take some time. Plan to engage your PMC at least a full week in advance of the June 5 deadline. PMC members, please make sure that the document is complete and that you are satisfied with its content before providing your approval. When I look at the extremely short (or non-existent) outside contributions sections on some IP logs, I grow concerned that some projects aren't doing enough to court the community and grow diversity. Please use the Release Review checklist to make sure that you've done all the necessary bits: http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews#Checklist Note that this checklist has been around for a long time. There should be nothing new or surprising here. I've noticed that a lot of projects do not have plans posted. This is an important and necessary part of the development process. Plan information can be entered directly in the release record in the Project Management Infrastructure. Providing a project plan in a standard format is required. Wrestling with XML is no longer required. It's easy. Please make this happen. Note that planning should happen at the beginning of a release cycle. PMCs, please impress the importance of this on your projects. Thanks, Wayne -- Wayne Beaton on behalf of the Eclipse Foundationhttp://www.eclipse.org/ [EclipseCon France 2013]http://www.eclipsecon.org/france2013 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev No virus found in this message. Checked by AVG - www.avg.comhttp://www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6275 - Release Date: 04/26/13
Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j
Hi David, From the b3 aggregator log, it appears that Code Recommenders is the one pulling in version 1.6.4. Is that on purpose? That is, do you purposely constrain/include that older version? Any chance to move up to the latest? Sure. Will look into this straight away. Andreas -- Codetrails UG (haftungsbeschränkt) The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Hudson Snapshot Instance OutOfMemoryError
Hi Our Scout RT Gerrit Job on the Hudson Sandbox fails with an OutOfMemoryError (https://hudson.eclipse.org/sandbox/job/eclipse.scout.rt/160/console): # # A fatal error has been detected by the Java Runtime Environment: # # java.lang.OutOfMemoryError: requested 2147483656 bytes for Chunk::new. Out of swap space? # # Internal Error (allocation.cpp:215), pid=32563, tid=2726484848 # Error: Chunk::new # # JRE version: 6.0_21-b06 # Java VM: Java HotSpot(TM) Server VM (17.0-b16 mixed mode linux-x86 ) # An error report file with more information is saved as: # /opt/users/hudsonbuild/.hudson/jobs/eclipse.scout.rt/workspace/hs_err_pid32563.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # [ERROR] Failure: hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel What is the best way to reach a person which can solve this issue? Should I open a Bug? Thanks for any insights Stephan --- Stephan Leicht Vogt Senior Software Engineer BSI Business Systems Integration AG Täfernstrasse 16a, CH-5405 Baden Phone (direct): +41 56 484 19 47 www.bsiag.comhttp://www.bsiag.com smime.p7s Description: S/MIME cryptographic signature ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j
Hi, From the b3 aggregator log, it appears that Code Recommenders is the one pulling in version 1.6.4. Is that on purpose? That is, do you purposely constrain/include that older version? Any chance to move up to the latest? Sure. Will look into this straight away. made the move to org.slf4j.api 1.7.2: http://download.eclipse.org/recommenders/updates/train/e43/?dir=plugins Hope that fixes the problem. If not, please complain (again ;-)! Andreas -- Codetrails UG (haftungsbeschränkt) The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j
Thanks for your quick cooperation ... I bet you will be happier with the newest version anyway ... at least I hope! Thanks again, From: Andreas Sewe andreas.s...@codetrails.com To: cross-project-issues-dev@eclipse.org, Cc: Marcel Bruch marcel.br...@codetrails.com Date: 05/17/2013 01:50 PM Subject:Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j Sent by:cross-project-issues-dev-boun...@eclipse.org Hi, From the b3 aggregator log, it appears that Code Recommenders is the one pulling in version 1.6.4. Is that on purpose? That is, do you purposely constrain/include that older version? Any chance to move up to the latest? Sure. Will look into this straight away. made the move to org.slf4j.api 1.7.2: http://download.eclipse.org/recommenders/updates/train/e43/?dir=plugins Hope that fixes the problem. If not, please complain (again ;-)! Andreas -- Codetrails UG (haftungsbeschränkt) The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 _ __ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j
Hi David, Thanks for your quick cooperation ... I bet you will be happier with the newest version anyway ... at least I hope! I bet we won't notice the difference: log.error(..) is still the same as always. Anyway, can you just double-check [1] that the other, SLF4J related plugins like ch.qos.logback.slf4j are also using the right version? Thanks. Best regards, Andreas [1] http://download.eclipse.org/recommenders/updates/train/e43/?dir=plugins -- Codetrails UG (haftungsbeschränkt) The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Kepler dates, IP Logs, and reviews
The contribution review tool is intended to assist a project in identifying IP contributions that come through Bugzilla. If your project is using Git and is pushing commits that are correctly annotated with author information, then this tool will be of no interest to you. Its main value at this point is mostly historical for most projects. I'll add a link to the IP Log generator from the project page. HTH, Wayne On 05/17/2013 02:26 AM, Ed Willink wrote: Hi Found it. It's lurking on the left of http://eclipse.org/projects/tools/ip_contribution_review.php, so if you ignore the rubbish from http://eclipse.org/projects/tools/ip_contribution_review.php you get the good old review. Regards Ed Willink On 17/05/2013 07:18, Ed Willink wrote: Hi What has happened to the old (very good) IP tool? It gave me a good auto-generated log for MDT/OCL that I could easily review. http://eclipse.org/projects/tools/ip_contribution_review.php is hard to find (no link from portal or project page) and gives me a list of over 600 bugs to review. No way. There have been zero IP contributions so I expect to do the job in 10 minutes not 10 hours. If there really is a change in diligence then please threshold it at resolution after Juno, since all pre-Juno bugs have been IP logged and approved. Regards Ed Willink On 26/04/2013 19:24, The Eclipse Foundation wrote: Kepler approaches. I'm starting to get IP Log review requests for the upcoming release. In at least two cases, I'm pretty sure that the submitter thought that the release date was in May. To be clear, here are the dates: May 24/2013 - Deadline to submit IP Logs for Kepler releases June 5/2013 - PMC-approved Review materials submitted to EMO June 12/2013 - Kepler Uber Release review June 26/2013 - Kepler release The IP Logs are not due for another month. It's still a little early, but it's perfectly acceptable to submit your IP log for review in advance of the actual required-by date. Just keep in mind that the log needs to accurately reflect the content that you're releasing; if you anticipate receiving any contributions from folks who are not committers, it might be a good idea to hold off for a while. While I'm at it, I'd like to make a plea to everybody to please try and honour the dates specified. There are a few projects that make a habit of submitting the required materials late; this causes a lot of stress for everybody involved. If you haven't started thinking about your IP Log and review documentation, now might be a good time to do so. I need to have you PMC-approved review documentation before EOB on June 5/2013. You can either do what we've been doing for years and submit this information as a presentation, document, PDF, or whatever. Or you can just enter review information directly in the release record in the Project Management Infrastructure. A few of you have already started doing the latter; my sense is that it is an easy way to assemble and provide this information. Please let me know if you think otherwise, or if there is anything that we can do to improve it. The PMC approval part is important. Get it approved. This may take some time. Plan to engage your PMC at least a full week in advance of the June 5 deadline. PMC members, please make sure that the document is complete and that you are satisfied with its content before providing your approval. When I look at the extremely short (or non-existent) "outside contributions" sections on some IP logs, I grow concerned that some projects aren't doing enough to court the community and grow diversity. Please use the Release Review checklist to make sure that you've done all the necessary bits: http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews#Checklist Note that this checklist has been around for a long time. There should be nothing new or surprising here. I've noticed that a lot of projects do not have plans posted. This is an important and necessary part of the development
Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j
Looks right to me ... but ... to be honest, I know a whole lot less about it than just about anyone else :) (e.g not sure you need all three fragments ... but, no idea how it is normally shipped/configured). So, I've passed on your question to the original bug, and added you to CC in case some of the people discussing it there have any comments. Bug 407797 - inconsistent mixture of org.slf4j.api and ch.qos.logback.slf4j Thanks again, From: Andreas Sewe andreas.s...@codetrails.com To: cross-project-issues-dev@eclipse.org, Date: 05/17/2013 02:07 PM Subject:Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j Sent by:cross-project-issues-dev-boun...@eclipse.org Hi David, Thanks for your quick cooperation ... I bet you will be happier with the newest version anyway ... at least I hope! I bet we won't notice the difference: log.error(..) is still the same as always. Anyway, can you just double-check [1] that the other, SLF4J related plugins like ch.qos.logback.slf4j are also using the right version? Thanks. Best regards, Andreas [1] http://download.eclipse.org/recommenders/updates/train/e43/?dir=plugins -- Codetrails UG (haftungsbeschränkt) The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 _ __ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Libraty piggy-back CQs
Hi Thanks; that's clear but is hardly sensible. I have a handful of PB CQs to raise and I suspect many other projects must do too. Since we are strongly encouarged to track the latest Orbit version, shouldn't there be an auto-PB CQ for any project that has a PB CQ for an Orbit library? Currently I see 20 Guava 10.x PB CQs 2 Guava 11.x PB CQs 0 Guava 12.x PB CQs 4 Guava 13.x PB CQs 0 Guava 14.x PB CQs With M7 changing the preferred Guava release to 12 that makes for 20 out of 20 projects in breach of IP policy. Regards Ed Willink On 17/05/2013 19:20, Wayne Beaton wrote: I believe that the Contribution Questionnaire page in the wiki [1] answers this. If it is unclear, either take a crack at clarifying it yourself or let me know I can take another run at it. The short version is that you need CQ for any library that project code uses directly. You do not require a CQ for any library that is used indirectly via another Eclipse project. I spelled this out in more detail on the wiki page. CQs are version-specific. You need a CQ for each version of a library that project code uses. It doesn't matter where project code comes from. If a tool like Xtext generates project code (i.e. code that goes into your source code repository, or dynamically-generated code that gets distributed in compiled form) that uses a library, this is considered a direct reference. HTH, Wayne [1] http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire On 05/17/2013 02:31 AM, Ed Willink wrote: Hi Wayne Can you clarify the policy on library piggy-back CQs? For MDT/OCL we initially used Guava indirectly through Xtext and so might not need a PB CQ although we did raise one since Xtext auto-generates source code for us with direct calls to the Injector class. Subsequently we have some manually written code that exploits Guava too. Our PB CQ has not updated from version 10, although Guava in Orbit is charging along through 11, 12 with 14 on the horizon. Are we at fault through not raising more PB CQs? Do I misunderstand the policy? Is the policy inappropriate for major evolving libraries? Regards Ed Willink ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation Learn about Eclipse Projects ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3336 / Virus Database: 3162/6332 - Release Date: 05/17/13 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Libraty piggy-back CQs
Also using Import-Package allows for provider substitution. You don't really know who the provider of the package dependency is by looking at a bundle manifest in isolation. Tom From: Wayne Beaton wa...@eclipse.org To: cross-project-issues-dev@eclipse.org, Date: 05/17/2013 02:06 PM Subject:Re: [cross-project-issues-dev] Libraty piggy-back CQs Sent by:cross-project-issues-dev-boun...@eclipse.org The issue is one of tracking who is using what third-party library. Right now, the tools that I use to scan the downloads directory almost do a good enough job to eliminate piggyback CQs altogether. Almost. The problem is that the tool only detects libraries that are actually distributed by the project. It works by file name alone. It fails to detect libraries that are pulled in from Orbit, for example. I think that the solution is to scan bundles for references to third-party libraries, but I'll need some p2 magic to sort that out, I think. Bash just isn't going to cut it. Does anybody know what p2 magic we can use to query a bundle for a definitive list of dependencies (including bundle and package imports?) Of course, this doesn't help us if a project isn't distributing OSGi bundles... Wayne On 05/17/2013 02:35 PM, Ed Willink wrote: Hi Thanks; that's clear but is hardly sensible. I have a handful of PB CQs to raise and I suspect many other projects must do too. Since we are strongly encouarged to track the latest Orbit version, shouldn't there be an auto-PB CQ for any project that has a PB CQ for an Orbit library? Currently I see 20 Guava 10.x PB CQs 2 Guava 11.x PB CQs 0 Guava 12.x PB CQs 4 Guava 13.x PB CQs 0 Guava 14.x PB CQs With M7 changing the preferred Guava release to 12 that makes for 20 out of 20 projects in breach of IP policy. Regards Ed Willink On 17/05/2013 19:20, Wayne Beaton wrote: I believe that the Contribution Questionnaire page in the wiki [1] answers this. If it is unclear, either take a crack at clarifying it yourself or let me know I can take another run at it. The short version is that you need CQ for any library that project code uses directly. You do not require a CQ for any library that is used indirectly via another Eclipse project. I spelled this out in more detail on the wiki page. CQs are version-specific. You need a CQ for each version of a library that project code uses. It doesn't matter where project code comes from. If a tool like Xtext generates project code (i.e. code that goes into your source code repository, or dynamically-generated code that gets distributed in compiled form) that uses a library, this is considered a direct reference. HTH, Wayne [1] http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire On 05/17/2013 02:31 AM, Ed Willink wrote: Hi Wayne Can you clarify the policy on library piggy-back CQs? For MDT/OCL we initially used Guava indirectly through Xtext and so might not need a PB CQ although we did raise one since Xtext auto-generates source code for us with direct calls to the Injector class. Subsequently we have some manually written code that exploits Guava too. Our PB CQ has not updated from version 10, although Guava in Orbit is charging along through 11, 12 with 14 on the horizon. Are we at fault through not raising more PB CQs? Do I misunderstand the policy? Is the policy inappropriate for major evolving libraries? Regards Ed Willink ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation Learn about Eclipse Projects EclipseCon France 2013 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3336 / Virus Database: 3162/6332 - Release Date: 05/17/13
