[Solved] Bugzilla - what's a usual response time from dev.s?

[christian_l]

Hi everybody,
I am having a problem with a bug where I am trying to figure out whether somebody is actually working on this or not. This is not a rant - I am well aware that developers are busy people and have to prioritize their efforts! I am basically trying to get feedback on how long things here usually take, and how I can figure out whether this particular bug report somehow fell under the developers' radar or not.

The bug report is here: https://bugs.freedesktop.org/show_bug.cgi?id=31814 and deals with a regression that happened somewhere between switching from OpenOffice to LibreOffice. Basically all chemical structures in document and presentation files are gone, which for me is a very big problem. Other people have reported this last November, and after four days the bug was assigned to somebody. For some time nothing happened, then six months later somebody else could not reproduce it, and marked it fixed. Two weeks later it was reopened - turned out the bug only seems to affect Linux systems. Another three months passed, and I added my own comments and a sample file, hoping that this would help clarify the problem and speed things up. Three weeks later, there is still no sign that any developer has actually read this after the bug had been reopened, or is considering to work on it. The person the bug was assigned to 11 months ago never commented on the bug at all.

Is this complete lack of feedback over such a long time scale normal around here? I would have expected to get at least a one-liner saying “Yes, I can reproduce it, but I'm busy with more critical stuff right now”, or “we can still not reproduce it”, or something. Without any feedback, I can only guess whether or not my and other people's comments have been noticed...

Thanks for any insights!
Christian

[Hagar Delest]

Hi and welcome to the forum!

In such case, you can try to ask on the dev mailing list. Devs are more active on such channels.

Please add '[Solved]' at the beginning of your first post title (edit button) if your issue has been fixed.

[r4zoli]

First thing, you needs to determine in what version of LibO this happens, and try always in latest version.

Second thing, you downloaded LibO from LibO site or use Linux distros own version, in the linux distros case not waste your time to submit in general LibO bugzilla, they will try to check it in general LibO version.

You needs to find a linux distro bugzilla and submit your bug there. The response will be the same, but will be the right place, if you have a time and will could try in LibO downloaded from LibO site, and if you could reproduce it, submit in Libo bugzilla. The bugs will be corrected, if the developers think, it is a bug which worth the effort.

[acknak]

Embedded objects, made with a Windows application, are generally not a good approach for cross-platform work. The best that can happen when you open the file on a non-Windows system, is that an image placeholder can be displayed for each object. The quality of that image placeholder can be pretty poor and the object can't be opened or edited unless the creating application is present.

Working in a .doc file format is further asking for problems.

That's really pushing the envelope, but surprisingly the file does display for me, using OOo 3.3.

[christian_l]

First thing, you needs to determine in what version of LibO this happens, and try always in latest version.

Hi, that's already done. It's part of the bug report. I even tried a recent nightly.

Second thing, you downloaded LibO from LibO site or use Linux distros own version, in the linux distros case not waste your time to submit in general LibO bugzilla, they will try to check it in general LibO version.

The nightly I tried was directly from the LibO website. Also, another comment in that bugzilla thread came from a Ubuntu user, while I am using Fedora. So I think it's not distro-dependent. I would assume that if I posted this on the Fedora bugzilla, they'd only direct me back here.

The response will be the same, but will be the right place, if you have a time and will could try in LibO downloaded from LibO site, and if you could reproduce it, submit in Libo bugzilla. The bugs will be corrected, if the developers think, it is a bug which worth the effort.

If I understand this correctly, you are not surprised that nobody answers to the already submitted bug for 11 months, then. OK, thanks!

[christian_l]

Embedded objects, made with a Windows application, are generally not a good approach for cross-platform work. The best that can happen when you open the file on a non-Windows system, is that an image placeholder can be displayed for each object. The quality of that image placeholder can be pretty poor and the object can't be opened or edited unless the creating application is present.

Working in a .doc file format is further asking for problems.

That's really pushing the envelope, but surprisingly the file does display for me, using OOo 3.3.

It's true that I could not edit the chemical objects under Linux, but I was still always able to see them (in excelent quality). The fact that this has been working in OOo for years is what's really frustrating here. And yeah, I would love to drop .doc files and windows all together, but i am working in a university environment, constantly sharing presentations and manuscripts with my collaborators, who for the most part are using windows or macs. So until the year of the Linux desktop finally arrives, I'm stuck with those formats...

[christian_l]

OK, I marked this as solved, even though some questions remain for me. Here's what I've learned, in case somebody stumbles upon this via a search:

Once a bug is assigned, new comments do get emailed to the assignee, even if the bug is marked "reopened", and even though he/she might not show up in the CC list. Between the history list and the CC list, you can see also what other devs might still be getting those messages, and who might thus be able to tell you whether the bug's assignee is in fact still alive.

Some developers give you a short answer that shows that your comments have been read, some don't. From the fact that nobody here answered with something like "wow, that's really weird" or so, I take it that such lack of feedback is not too uncommon.

[acknak]

I think that's a good summary, with one possible exception:

Between the history list and the CC list, you can see also what other devs might still be getting those messages, and who might thus be able to tell you whether the bug's assignee is in fact still alive.

As I understand it, making personal contact through the bug tracker is not a good approach. If you have a question as to the status of a bug, it's best to simply add it as a comment. That way, it's part of the public record and anyone can see it and respond to it.

I'm not a developer, but I have submitted a few bug reports. In my experience, before a bug has its status changed to "STARTED" it's perfectly normal to get no response in the comments. As far as possible, bugs are not assigned to someone who is likely to just disappear. If a developer does leave, the assigned bugs are not just left to wither; they are re-assigned to someone else who is active.

It's just a fact of life with a large project like OOo that have far more bugs than developers: they can't work on everything or nothing will get done. I expect that to be even more true now that OOo has no paid development staff.

Something to be aware of: the process and policies for dealing with issues may change now that OOo is developed under the Apache Foundation.