Re: [dev] amount of stopper / regressions for 3.1 release
Matthias B. wrote: On Thu, Apr 2, 2009 at 3:23 PM, Juergen Schmidt wrote: Hi Mathias, Matthias B. wrote: On Wed, Apr 1, 2009 at 11:27 PM, Maximilian Odendahl wrote: can you name some of these regressions which prevent you in using 3.1? http://www.openoffice.org/issues/show_bug.cgi?id=100374 and http://www.openoffice.org/issues/show_bug.cgi?id=100718 thanks for the info. Do you have more issues? Your former email sounds of course much more worse. I was referring to the past. There have been other bugs and backwards-incompatible changes in the past that broke things for us. For instance there was the backwards-incompatible change of the classloader, I think in 2.3. Then there was the backwards-incompatible change of the bootstrap mechanism with 3.0. The bugs I do not remember. We've reported 131 issues so far (according to my query). It's hard to keep track :-) First of all thanks for all the issue reports. 131 issues over which period? You heavily use OO and of course the API. Probably for your use-cases every single reported bug was a showstopper. But what do you think. Are they showstopper issues for all others as well or are they more normal issues where we have thousands from? How many issue would be P1 or P2 taking the OO.org issue guide lines into account? The bootstrap change was necessary because of the new structure and a rebuild including the newer bootstrap glue code solved the problem. Sometimes it is simply necessary to change things this way and of course the changed bootstrap glue code is backward compatible. Maybe the communication wasn't good enough. But i see your point. What exactly do you mean with the classloader change? I am not 100% sure what you mean. I think we never ever have defined that all jars in the classes directory are in the classpath. That was an implementation detail. In case of components we load them now in a new classloader for various reasons. But that shouldn't be a real problem if you use manifest entries in your jar correct to reference for example other non component jars in your oxt. Then there are things that we haven't reported because they cannot be reproduced reliably and there are more of those in 3.x than in earlier releases. For instance OOo 3.x sometimes freezes when I click into the UI "too soon". Furthermore OOo 3.x feels slower than 2.4. All in all, the quality seems to have gone done with 3.x. mmh, i don't say that it is wrong but it is also hard to reproduce for us as well. For crashes it is very helpful to use the crash reporter and we can depending on the counts focus on the most important issues. Two issue, both submitted really late for a 3.1 release. That is not optimal and of course it was really late. You have pointed out that you switched to dev snapshots early but because of too much problems you moved back. Have you reported problems at this time? No. When I get a segfault right away simply launching swriter I do not bother to report it. Same goes if OOo won't build in the first place (e.g. because of missing modules). These things are so obvious that they must be known. BTW, those were trunk builds. I think someone else has already mentioned that trunk should be kept somewhat stable. It makes people lose confidence if it doesn't even start up (or build). After all, the next version will be branched off from trunk. If trunk is broken, the next version will be initially broken. i do not disagree. Well a build problem is of course bad but hey it is fixed asap in the next version, right? Anyway the more difficult problem is that you build the office on your own and many things can go wrong. I don't say that you build wrong but i see a problem here. I would suggest that you use first official dev snapshots. But i am not sure, building it on your own should work also. Using official snapshot would maybe a little bit easier for all. I think it is important that you give us feedback or that you report problems/issues asap so that we have time to address this problems. I don't know if you have reported the problems earlier to somebody or if you have simply ignored them until your latest evaluation. We report issues as soon as possible for us but you have to understand that filing quality bug reports with test cases (which we usually do) takes time. Issue 100718 has taken me a complete day to analyze and construct a test case for. I can't simply drop my regular work for a whole day whenever an OOo issue comes up. Especially when it's early in the OOo release cycle there's a strong motivation to just wait and see if the bug gets fixed. i understand that and good bug reports are highly appreciated. But if you don't have time to produce a test case you can at least report the problem on the mailing list. Maybe others had the problem and already submitted an issue. Again, the quality of trunk and early milestones is partially to blame. If I were under the impression that trunk/milesto
Re: [dev] amount of stopper / regressions for 3.1 release
On 2009.04.02. 17:41, Matthias B. wrote: ... Two issue, both submitted really late for a 3.1 release. That is not optimal and of course it was really late. You have pointed out that you switched to dev snapshots early but because of too much problems you moved back. Have you reported problems at this time? No. When I get a segfault right away simply launching swriter I do not bother to report it. Same goes if OOo won't build in the first place (e.g. because of missing modules). These things are so obvious that they must be known. oh, i have thought the same, and how wrong have i been often. it could be some minor change in your environment that causes this, so that nobody else will see that. it is worth at least doing a quick query on issuezilla or asking on the irc. if you don't report such problems, you might find out months later you still are the only one with them. BTW, those were trunk builds. I think someone else has already mentioned that trunk should be kept somewhat stable. It makes people lose confidence if it doesn't even start up (or build). After all, the next version will be branched off from trunk. If trunk is broken, the next version will be initially broken. that depends on whether you mean trunk from vcs, or trunk snapshots. trunk snapshots - definitely. trunk from vcs - well, that is acceptable to break now and then, as long as it's also fixed soon ;) I think it is important that you give us feedback or that you report problems/issues asap so that we have time to address this problems. I don't know if you have reported the problems earlier to somebody or if you have simply ignored them until your latest evaluation. We report issues as soon as possible for us but you have to understand that filing quality bug reports with test cases (which we usually do) takes time. Issue 100718 has taken me a complete day to analyze and construct a test case for. I can't simply drop my regular work for a whole day whenever an OOo issue comes up. Especially when it's early in the OOo release cycle there's a strong motivation to just wait and see if the bug gets fixed. Again, the quality of trunk and early milestones is partially to blame. If I were under the impression that trunk/milestones are supposed to be of high quality, I would be more inclined to spend time examining bugs early. But since I'm under the impression that trunk breakage is normal, that merging buggy code is normal and that all in all it's normal that hordes of new bugs are introduced that won't be fixed until late in the release cycle, I think to myself: "Well, they know that their code is broken. There's no need for me to waste my precious time constructing test cases for bugs they are probably already aware of." while this might seem unfair at first moment to devs, i'd like to point out that i share the same thinking. i still do take my time to report crashes, but if i know (or only even get the impression) that there are many, many known bugs, i do not bother to report them all - i've been bitten countless times by reporting issues at a stage when there's shitload of work to do anyway, so that nobody looks at those bugs for a long time. then, somebody comes over and says "oh, retest this with latest version". ugh, sometimes software interface has changed in the meantime so i can't even map old testcase to the new version :) absolutely no offense to devs, qa and others involved - that's just what your users can feel like sometimes :) Matthias -- Rich - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
On Thu, Apr 2, 2009 at 3:23 PM, Juergen Schmidt wrote: > Hi Mathias, > > Matthias B. wrote: >> >> On Wed, Apr 1, 2009 at 11:27 PM, Maximilian Odendahl >> wrote: >>> >>> can you name some of these regressions which prevent you in using 3.1? >>> >> >> >> http://www.openoffice.org/issues/show_bug.cgi?id=100374 >> >> and >> >> http://www.openoffice.org/issues/show_bug.cgi?id=100718 >> > thanks for the info. Do you have more issues? Your former email sounds of > course much more worse. I was referring to the past. There have been other bugs and backwards-incompatible changes in the past that broke things for us. For instance there was the backwards-incompatible change of the classloader, I think in 2.3. Then there was the backwards-incompatible change of the bootstrap mechanism with 3.0. The bugs I do not remember. We've reported 131 issues so far (according to my query). It's hard to keep track :-) Then there are things that we haven't reported because they cannot be reproduced reliably and there are more of those in 3.x than in earlier releases. For instance OOo 3.x sometimes freezes when I click into the UI "too soon". Furthermore OOo 3.x feels slower than 2.4. All in all, the quality seems to have gone done with 3.x. > Two issue, both submitted really late for a 3.1 release. That is not optimal > and of course it was really late. You have pointed out that you switched to > dev snapshots early but because of too much problems you moved back. Have > you reported problems at this time? No. When I get a segfault right away simply launching swriter I do not bother to report it. Same goes if OOo won't build in the first place (e.g. because of missing modules). These things are so obvious that they must be known. BTW, those were trunk builds. I think someone else has already mentioned that trunk should be kept somewhat stable. It makes people lose confidence if it doesn't even start up (or build). After all, the next version will be branched off from trunk. If trunk is broken, the next version will be initially broken. > I think it is important that you give us feedback or that you report > problems/issues asap so that we have time to address this problems. I don't > know if you have reported the problems earlier to somebody or if you have > simply ignored them until your latest evaluation. We report issues as soon as possible for us but you have to understand that filing quality bug reports with test cases (which we usually do) takes time. Issue 100718 has taken me a complete day to analyze and construct a test case for. I can't simply drop my regular work for a whole day whenever an OOo issue comes up. Especially when it's early in the OOo release cycle there's a strong motivation to just wait and see if the bug gets fixed. Again, the quality of trunk and early milestones is partially to blame. If I were under the impression that trunk/milestones are supposed to be of high quality, I would be more inclined to spend time examining bugs early. But since I'm under the impression that trunk breakage is normal, that merging buggy code is normal and that all in all it's normal that hordes of new bugs are introduced that won't be fixed until late in the release cycle, I think to myself: "Well, they know that their code is broken. There's no need for me to waste my precious time constructing test cases for bugs they are probably already aware of." Matthias - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Participate in OpenOffice.org
Hello, my name's Dien. I'm a student and I want to practice more about java. I particapate in OpenOffice.org. But I'm newbie in java so I don't know how where to begin. Can you tell me some idea about it. Thank you very much.
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Mathias, Matthias B. wrote: On Wed, Apr 1, 2009 at 11:27 PM, Maximilian Odendahl wrote: can you name some of these regressions which prevent you in using 3.1? http://www.openoffice.org/issues/show_bug.cgi?id=100374 and http://www.openoffice.org/issues/show_bug.cgi?id=100718 thanks for the info. Do you have more issues? Your former email sounds of course much more worse. First i would suggest that you file issues with component "api" for this kind of API issues independent of the application area. In this case i get it on my radar and can at least try to help. Until today we still have our compatibility statement and we have to take this issues seriously. Two issue, both submitted really late for a 3.1 release. That is not optimal and of course it was really late. You have pointed out that you switched to dev snapshots early but because of too much problems you moved back. Have you reported problems at this time? I think it is important that you give us feedback or that you report problems/issues asap so that we have time to address this problems. I don't know if you have reported the problems earlier to somebody or if you have simply ignored them until your latest evaluation. You can use the direct contact to the devleopers via the mailing and can talk with us. I am sure that we won't ignore you when you report such problems. I am sure that we take it serious. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OpenOffice.org Java JRE search paths
Hanno Meyer-Thurow wrote: On Wed, 01 Apr 2009 10:45:35 +0200 Jochen wrote: Hanno Meyer-Thurow schrieb: So, in short it would be these three points of interest: - change Java JRE search paths to one (set by configure option) This is currently not supported. I can add that. :) I am not clear what exactly you try to achieve. Is it that you want only look in exactly one place for an installed JRE? What is meant with "configure option" - accept a symlink as the base directory for a Java JDK/JRE During the search for JRE installations the JREProperties.class program is carried out for each found JRE. This program reads out the system properties and writes them to stdout where the java framework reads them from and the checks things like java.version java.vendor java.home Okay, I finally got halfway through. util.cxx is patched so that only one path is checked for Java RE and the unresolved base directory is used. Now I have to find the code that creates the java configuration since there is the resolved path written to instead of the unresolved one. May you give me another code pointer for this, please. Unless it is sourced from JREProperties that I will check. jvmfwk/source/elements.hxx:CNodeJava Please keep in mind that if you want to contribute the support of links in OOo that one also needs the check if the used Java complies with the requirements. And it must be defined what happens, when this is not the case. Joachim Regards, Hanno - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
On Wed, Apr 1, 2009 at 11:27 PM, Maximilian Odendahl wrote: > can you name some of these regressions which prevent you in using 3.1? > http://www.openoffice.org/issues/show_bug.cgi?id=100374 and http://www.openoffice.org/issues/show_bug.cgi?id=100718 Both scheduled for 3.2. Matthias - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
RE: [dev] filters as extensions -- lucky!
> -Original Message- > From: mikhail.voyte...@sun.com [mailto:mikhail.voyte...@sun.com] > Sent: Tuesday, March 31, 2009 5:58 PM > > By the way, if two extensions install the same filter, the result is > unpredictable if I remember correctly. Hello, Indeed it works! But it needs a really clean install of OOo, that is, after a really thorough uninstall of everything there might have been before: - user dir - program dir - registry (conflicts can be nasty and invisible) Not only does it work, but it's quite powerfull too; I was able to package an xsl filter combined with a macro that launches it, and a menu element that launches the macro... all in one extension... it's relly neat! ;-) Many thanks for the hint! Regards, EB - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Setting up with Visual Studio 2008
Quentin Headen wrote: Hello. My name is Quentin. I am a high school student, and I am interested in computer programming. I want to get into the open office development to help polish my already learned skills in C++ and Java. I have Visual Studio 2008 professional installed on my computer. I know you have information on your site, but I find the information kind of overwhelming. Where should I go and what do I have to do to get Visual Studio 2008 to compile OpenOffice.org source code? Please let me know. Hi Quentin, Please look at the following wiki page which describes in detailed steps how to build OpenOffice.org with Visual Studio 2008. http://wiki.services.openoffice.org/wiki/Building_OOo_with_Cygwin_on_Windows Regards, Carsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Setting up with Visual Studio 2008
Hello. My name is Quentin. I am a high school student, and I am interested in computer programming. I want to get into the open office development to help polish my already learned skills in C++ and Java. I have Visual Studio 2008 professional installed on my computer. I know you have information on your site, but I find the information kind of overwhelming. Where should I go and what do I have to do to get Visual Studio 2008 to compile OpenOffice.org source code? Please let me know. Thank you - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi, for 3.1. The result is that OOo 3.1 will be the worst OOo ever from our POV. It's so broken that it's impossible to use with our app and our organization (that's over 9000 OOo installations) will have to completely skip 3.1 and pray for 3.2 to be better. can you name some of these regressions which prevent you in using 3.1? Best regards Max - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
