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: [email protected]
For additional commands, e-mail: [email protected]
