I found out that openoffice.org are running a user survey, and thought that should be more public.
Please help improve the OpenOffice.org office suite by completing this survey. It will take about 15 minutes and will increase our understanding of your requirements and expectations for the OpenOffice.org software. You will have the opportunity to make comments or suggestions at the end of the survey.
So, please help and fill the survey (it realy doesn’t take 15 minutes)…
Filed under Openoffice.org, QA stuff
Openoffice.org Ninja already covered some of the new RTL features with openoffice.org 3.1, mainly RTL enabled controls (#30631). But following the bugzilla issues, it seems that version 3.1 also includes fixes for more RTL related issues. Here is a list of some of the issues I encountered:
I’d like to thank everyone envolved with the fixes of these issues.
Filed under i18n & l10n, Openoffice.org, Proud to use free software, QA stuff
While working with kSar to visulize sar’s statistics, a friend found a bug with kSar.
Most IT people don’t think they can have access to the developers, I reminded my friend that we’re dealing with an open source application and we should report a bug or at least check the bug with the develpers.
He wrote a message in the kSar forums, and the answer, in the form of a new minor version came 4 hours later. We testing the fix and were very happy.
I can just hope all my bugs will be solved so quickly (:
So, please don’t be shy about your problems with free software. Most developers will be happy to get a good bug report and help you. I believe that’s specially true about developers of small applications who are just happy to hear people are using their software.
I’ve encounterd a bug in launchpad about adding a new gnucash translation to the Hebrew language pack. Nothing out of the ordinary excepts that for every upstream translation update you should file a bug to update the language pack.
A new Hebrew tranlation was released in version 2.2.6 as part of the upstream release. In Debian the new translation appeared with the sources, but in Ubuntu, the translation is lost since it’s not in Rosetta.
As I see it, such translations are falling between the chairs, since upstream won’t check the distribution for each translations, and the users don’t check upstream’s changelog for translation changes (and only major translation changes appear on the changelog).
Another issue, the the need for Ubuntu to duplicate translation into Rosseta, although they come only from upstream (like in this case). I seems to me as a waste of time, and something that only creates problems. After such an import you can easy find an old transation ships in parallel to newer sources. What happens if many strings changes in the source ? You get many strings in English…
Filed under Debian GNU/Linux, i18n & l10n, QA stuff, Ubuntu
The 2nd bug triage began with 285 bugs, which grow to around 310 bugs, since during the 4 months of the triage more bugs were reported.
So, I’m glad to announce the beginning of (my) 2nd openoffice.org bug triage. This triage targets 285 bugs out of 330 open oo.org bugs. The selected bug are ones which were reported against versions lower the 2.3.1 or have no version information at all.
At first, the triage advanced quickly with 21% of the bugs processed during the first 24 hours and 40% during the first 10 days. This left a long trail of bugs to handle manually.
The triage began for version 2.3.1, but was delayed to let version 2.4.0 to propagate into Lenny, as that was Rene’s preferable version to release with. When the triage resumed in late April, I had a 2.4.0 available in all of our repositories (sid, testing and backprots). Which meant that everyone could verify their bugs against the same oo.org version. Bug triaging heaven (:
Two thirds (66%) of the bugs were closed in this triage, most of them after a check from the submitter or myself and a few after the submitter was unresponsive and I couldn’t verify the bug myself.
Verifying the bugs myself is the most demanding part of the triage. Reading each report and understanding the problem takes a lot of time. Reproducing the problem usually takes less time than understand it. That’s way have test cases attached to bug reports are so important.
In several cases the instructions were so simple I could just open the file, check something and verify the bug. That was done in a robotic manner or in a monkey like one. These kind of attachments enables a lot of people to help with triaging, even if the lake the technical background of the program in subject.
So after closing 200 bugs and verifying around 100+, the oo.org bug count is set to 140 outstanding bugs, and 70 bug being forwarded to upstream. Except from about 10 bugs, all of the remaining 130 bugs are relevant for version 2.4.0. No need to wonder if the bug still occurs before reading the report…
Filed under Debian GNU/Linux, Openoffice.org, QA stuff
I checked the Debian firefox bugs page and noticed a new bug was reported against firefox. Checking the bug report showed the bug is new as it reported against version 3.0b5. As there’s now firefox package in debian testing/unstable that was weired enough.
Reading the bug report revealed these details:
Package: firefox
Version: 3.0~b5+nobinonly-0ubuntu3
and
Debian Release: lenny/sid
500 hardy-updates us.archive.ubuntu.com
500 hardy-security security.ubuntu.com
500 hardy us.archive.ubuntu.com
I mailed the user to see why does he reports Ubuntu’s bugs to Debian. He replied that he’s using the reportbug-ng program and wasn’t aware that his bug have been sent to Debian.
I check the reportbug and reportbug-ng in Ubuntu and found that reportbug has the needed patch for Ubuntu:
diff -pruN 3.39/reportbug.conf 3.39ubuntu3/reportbug.conf
--- 3.39/reportbug.conf 2004-12-06 13:59:04.000000000 +0000
+++ 3.39ubuntu3/reportbug.conf 2007-10-25 07:22:47.000000000 +0100
@@ -6,7 +6,7 @@
# severity normal# BTS to use
-#bts debian
+bts ubuntu
# See ‘reportbug –bts help’ for a current list of supported BTSes# Submission address: default is ‘submit’
but since hardy reportbug-ng package in Ubuntu is identical to the one in Debian.
$ rmadison -u ubuntu reportbug-ng
reportbug-ng | 0.2007.10.30~feisty1 | feisty-backports/universe | source, all
reportbug-ng | 0.2007.06.27 | gutsy/universe | source, amd64, i386, powerpc
reportbug-ng | 0.2007.10.30~gutsy1 | gutsy-backports/universe | source, all
reportbug-ng | 0.2007.10.30 | hardy/universe | source, all
reportbug-ng | 0.2008.03.28 | intrepid/universe | source, all
Doing more checks reveals that this is a known problem in Ubuntu and is already reported at Bug #175508. This was also discussed three weeks ago on “Ubuntu Open Week – Reporting Bugs“.
A quick look at the reportbug-ng code makes it clear that reportbug-ng will require more work to support the Ubuntu BTS. There were also some comments about the configuration for Ubuntu in reportbug, as it just send the reports to ubuntu-users mailing list and not to the real BTS at https://bugs.launchpad.net/ubuntu/.
I’m still not sure what to do about the bug. On one hand, that package originates in Debian, and the bug is probably relevant. On the other hand, the cause might be a change from Ubuntu. In any case, I
don’t see the user following our BTS, and I don’t way to fixed package (if and when created) to propagate to Ubuntu.
Filed under Debian GNU/Linux, QA stuff, Ubuntu
It took half a year (including a long pause), and the Firefox triage is finally over. The last part, reviewing 120 bug reports took about a month. Starting with 324 bugs, the triage ended with 10 open bugs which I left for the maintainer to handle himself.
Although I didn’t keep record about the exact numbers about how many bugs were found to be fixed, it seems that ~250 bugs were closed (fixed, not relevant any more, whatever…). This leaves ~70 bugs to be valid (all reassigned to Iceweasel and got the right version info).
As I see it, the biggest problem of the large package maintainers have is to figure out if the bug is Debian specific or upstream only. The latter should be reported upstream by the users (when possible) to lower the pressure on the maintainers.
I my recent triages I saw a lot of upstream only bugs reported only in Debian, since the maintainers can’t be just “bugs forwarders”. It might work well in small packages, but this doesn’t scale up. So when possible, please try and report bugs upstream…
Anyway, I’ll probably initiate another triage for Iceweasel when version 3.0 will enter testing (probably post Lenny).
Filed under Debian GNU/Linux, Mozilla, QA stuff
