Matthias B. wrote:
On Thu, Apr 2, 2009 at 3:23 PM, Juergen Schmidt <[email protected]> wrote:
Hi Mathias,
Matthias B. wrote:
On Wed, Apr 1, 2009 at 11:27 PM, Maximilian Odendahl
<[email protected]> 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/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."
mmh, i agree that milestones should have ideally a reasonable quality
and that the trunk should be also in a good shape. But your last
sentence irritate me, do you think that this is the way how open source
should work?
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
