Am 09/04/2011 05:10 PM, schrieb Pedro F. Giffuni:
--- On Sun, 9/4/11, Marcus (OOo)<marcus.m...@wtnet.de>  wrote:
...
Example 1:
- A posting in LO mailinglist from Sept 2010 says:
"Creating a 'bug' saw no action in 3 years....
Here is hoping that posting the patch to this
new project will :-)"
(There goes one developer that will probably
think it twice before submitting new patches here)

Sorry, clearly not a stopper for me. It doesn't fix a bug
but introduce a new feature. This shouldn't be a stopper
candidate.


Nahh.. you haven't been doing your homework: that issue was
indeed a bug and the issue has been fixed now. I was
highlighting the effect of ignoring bugs for too long
though: it has an influence on the community as such.

How should I do better research when you don't give me an issue ID? ;-) So, of course I cannot know that it is a bug.

Example 2:
Bug 7065 (Which Marcus considers not to be a
showstopper) says in 2003:
"I think it is a mistake to future this bug. Page
numbering is a very important function of all
worprocessing software and its discoverability must
at least be increased."

When an issue is open und unsolved since 2003 then it is
sad. No doubt.
However, it's still not an issue that should suddenly stop
a release.

And after that there are 13 issues closed as
duplicates to this same bug.

Yes, someone has to review the patches, and the
applied
fixes won't necessarily match the submitted diffs or
what
LibreOffice committed but we do have a good starting
point to fix these issues and the wider community has
seen a value in fixing them so I do think they have a
higher priority.

Yes and no. It doesn't depend from where the issue or patch
comes or how
old it is. It's about the issue itself, what part of the
application it covers and its severity.


Which is all subjective and basically translates to "whatever
a random developer feels he should be working on today".

Not if the most of us have the same opinion. Then it is no longer subjective.

Come on.. let's admit: bug fixing never follows a coordinated,
well developed, plan to improve our product, at least not
in a volunteer project.

Why not? Do you like to work in chaos where everybody is doing something but not together? I hope not. ;-)

What I am saying here is that setting goals is good and a new
Apache release is not around the corner so tagging some bugs
for now as release blocker (or some other less obliging tag
for what I am concerned) doesn't really mean nothing.

Right, but not all of these 24 issues are blocker. Maybe the one and other.

Marcus

Reply via email to