AbiWord Weekly News #92, (2002, week 20, released 2002.05.20)

Welcome to issue 92 of the AbiWord Weekly News.

Continued work on new features and fixing of various Bugs.

This week the number of RESOLVED Bugs has reached 72. We need people to help verify that the Bugs have indeed been fixed. Get a snapshot build of AbiWord to help out with this! I also noticed that I'd forgotten to update the graph links in the past two issues, so be sure to have a good look at the graph this week :)

In this issue:

• CVS Stats
• Bug Update
• Latest Releases
• On the Mailing List
• Special Interest

Editor(s) of this issue: Jesper Skov

CVS Stats

Bug Update

Here's the AbiWord bug update for the last week. If you can spare some time, please help us triage the bugs - you don't need to be a programmer to do this.

Bug Statistics

Bug Votes

These are the week's Top 20 Bugs in the categories problems and requests for enhancements. Influence next week's results by casting your own votes.

Verified Bugs

In the past week, the following Bugs have been verified as fixed. The listed Bugs have all been put in RESOLVED mode as either FIXED or WORKSFORME and have then been verified by the people listed below. Other causes of resolving a Bug (e.g. as INVALID) are not tracked since they usually do not represent a fixed problem.

To get your name in neon, help QA the Bugs. If you want your name rather than your email address to appear, drop me a line.

Latest Releases

Here are links to the latest official releases of AbiWord for various architectures and operating systems.

These are links to snapshot builds of AbiWord for a subset of the supported architectures/operating systems.

Note that the snapshot builds may not work (at all!), but are likely to include more features and have fewer bugs than (older) official releases. Use the official releases for "production systems" and the snapshot builds for testing and when you want to help with Bug triaging.

On the Mailing List

Traffic on the developer mailing list has settled at about 200-400 postings per week.

You may also find interesting threads on the user and documentation lists (unfortunately the archive for the latter is broken at the moment).

This week, interesting topics on the developer list included:

1. Commit: ABW imports metadata: Dom added support for meta data in the documents. MS Word and Star Office plugins have been updated to support import/export of these, and there's a new dialog for editing document meta data in AbiWord. There have also been several long threads on what types of meta data tags to use and how to localize these. See the mailing list archive for all the details if you are interested.

2. Re: Hancom Office 2.01 for Linux (fwd): Alan Horkan decided to get in touch with Hancom after reading an interview with Bart Decrem about Hancom Office. Friendly folk, it seems, and happy to keep a communications channel open. Dom later posted a summary of stuff he'd discussed with Bart Decrem. First result of this will be the creation of a Hancom Office importer/exporter plugin, which Christian Biesinger started working on.

3. commit: Stable: Backport bonobo stuff: Martin backported the bonobo support to the stable branch. That means AbiWord 1.0.2 on GNOME will be usable as a plugin from Evolution and Nautilus.

4. 1.0.x STABLE RELEASE MAINTAINER: Hubert Figuiere and Mark Gilbert (aka MG, aka Blue Lizard) will be the stable release maintainers.

5. Glowing review on MSNBC, Congrats!: MSNBC reviwed AbiWord. Nice one. We also know that Washington Post has one coming very soon.

6. hey, evangelists! we're number two!: Second most popular project on SourceForge. Not bad at all!

7. Fwd: Abiword manual and software translation to Portuguese: Wanderley M Ceschim offered to translate the AbiWord user documentation into Portuguese. We would love to see other volunteers to do translations for other languages - it would be an ideal way for users without programming abilities to help make AbiWord better.

8. commit: Refactor the fl_Layout classes: Martin keeps working on the backend changes necessary for table support, among other things.

9. Commit (Head): WordPerfect Exporter beginnings: Marc Maurer has started working on a Word Perfect exporter. Interesting.

10. revision marks: Discussions on the design of revision marks started this week. Tomas seems to be driving the effort, with David providing valuable user-experience insight. Paul and Christian have also been sticking their heads into the fire. And late in the week, Tomas even committed a framework for parsing the discussed syntax for keeping track of revisions.

Special Interest -- BugZilla Changes - By Jesper Skov

A couple of weeks back, Hub and I reverted/updated the AbiWord BugZilla code to match that used by Mozilla. The primary reason for doing this was to make it easier to update BugZilla in the future.

Since the AbiWord version of BugZilla had a different set of Bug states, people who were used to it may be a bit confused about the new Bug states. So here's a quick overview of a Bug's progress through the system, and who are responsible for getting the Bug there.

• UNCONFIRMED: This is a Bug's initial state, which it is created with when it is reported. The meaning should be obvious: only the reporter has experienced the problem, it has not been confirmed by anyone else. Everybody, developers and users, can create Bugs.

• NEW: When a Bug has been confirmed by a different person than the reporter, it should moved to this NEW state. The meaning is that here is a new Bug that has not been encountered before (this is an important point; if the Bug has been encountered before, it should instead be resolved as a duplicate). Everybody, users and developers, can move a Bug to the NEW state, assuming they are able to reproduce the problem and didn't report the Bug.

• ASSIGNED: A developer can claim a Bug by moving it to the ASSIGNED state. Only developers can move a Bug to this state.

• RESOLVED: When the developer belives the Bug has been fixed, it is moved to the RESOLVED state. Only developers can move a Bug to this state.

• VERIFIED: When a RESOLVED Bug has been verified as fixed by someone, preferrably the reporter or another user who was able to reproduce the problem earlier, it is moved to the VERIFIED state. Everybody, users and developers (but preferrably the reporter), can move a Bug to this state. This is the final state of a Bug - it means the problem has been verified fixed.

• REOPENED: If a RESOLVED Bug does not appear to have been fixed after all, the Bug is reopened. Everybody, developers and users, can reopen a Bug if they find that the problem reported in the Bug persists.

• CLOSED: This state should only be used for Bugs that should never have been filed originally, or for issues that are obsoleted (an example would be a problem with the old Windows installer, which has now been replaced with NSIS). Only developers should move a Bug to this state.

There are other things that are good to know about the Bug database. Please see this link for more information.

Finally, it's worth pointing out that keeping the Bug database tidy makes it simpler for the developers to keep track of where the problems are. Ideally, there should only ever be Bugs in the NEW state (waiting for developers to pick them for fixing) and in the VERIFIED state (after they have been fixed). Every user of AbiWord is able to help see to that the Bugs are only in those two states, and thus help reduce the amount of time developers need to spend on keeping the Bug database tidy.