openoffice-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: AOO-Members dont forget voting
Date Sat, 20 Jul 2013 22:43:13 GMT
On Sat, Jul 20, 2013 at 3:22 PM, Scooter <> wrote:
> Good Afternoon Rob & Group,
> I whole heartily agree with your summation.
> I would much prefer the slower paced actual fixing and additions that
> worked, then the fastpace "maybe it will work" and see if the users find the
> problems the developers missed.
> I don't stay abreast of LO, since I'm not using LO. My opinion is that there
> seems to be less to writer then there used to be. the dictionary is now
> working. Hopefully, a better update can be established so the user doesn't
> have to figure out whether they have the latest or not. Possibly some way to
> notify of upcoming updates?

In OpenOffice you should be able to do a Help/Check for Updates via
the menu.  Also, OpenOffice 3.4.1 checks for updates every week (by
default) and notifies the user if there is an update available.


> I WAS happy with v3.3, but I'm not not a heavy user of AOO, because it isn't
> 100% compatible with Microsoft Office, especially in the spread sheet
> department. I need converted "xls" to work with my AutoCad software, which
> currently it will not. That's mostly the fault of AutoDesk, who doesn't keep
> up with new world of office software. I am not one to hang on to expensive
> Office software because of one program that requires its usage.
> I am happy that Open Office is alive and progressing at a solid pace of
> excellence. I'm also ecstatic that its mainline rather then in "Incubation",
> that word gave me the shivers.
> Take Care.
> Scooter
> College Park, MD USA
> Rob Weir wrote on 7/20/2013 11:33 AM:
>> On Sat, Jul 20, 2013 at 7:49 AM, Virgil Arrington <>
>> wrote:
>>> On Friday July, 19, 2013, Rob Weir wrote:
>>>> We've discussed AOO 4.0 many times, on the blog and in social media,
>>>> and this has been covered in the press.  Yes, we don't issue a press
>>>> release every week or every time we change code indentation, like some
>>>> other projects seem to do.  But we do take care of major
>>>> announcements.
>>>> I think the pace of development is one reason for the better quality.
>>>> I'd like to release more often as well, but I don't want to
>>>> compromise on quality.  But I think there is room for improvement
>>>> here.  And we are discussing having a public beta for AOO 4.1.
>>> I have complained on the LO user's list of its pace of releasing new
>>> versions. There are several to choose from at its download page, and the
>>> latest often contains bugs that had been fixed in earlier releases. It
>>> can
>>> be quite frustrating to download an update only to find a bug that you
>>> had
>>> thought was fixed.
>>> But...
>>> The slow pace of development at Apache is equally frustrating. AOO 3.4.1
>>> is
>>> a nice program ... except for the inability of the U.S. English version
>>> to
>>> properly hyphenate words (See bug 119087).  This bug has been around for
>>> years preventing the use of AOO for serious work in America when
>>> hyphenation
>>> is required. I assume (perhaps incorrectly) that it will be corrected in
>>> Ver. 4, but it has been frustrating to wait for Apache to release a new
>>> version until it gets everything right. Perhaps some sort of interim
>>> release
>>> fixing known and critical bugs could be made.
>>> Surely there can be some compromise between LO's torrid release pace and
>>> AOO's seemingly non-existent pace.
>> I think the compromise then is with quality.
>> Think if it this way:  any release has fixed and variable costs.  The
>> main fixed cost is testing.  Any release, no matter how small, needs
>> to be tested.  And given the complexity of AOO (from a code and
>> architecture viewpoint) this means a test of every area of the
>> product.  We have over a thousand test cases defined for AOO that we
>> try to run on all major platforms before we release.  This is a fixed
>> chunk of work and it can take a couple of months.  The variable costs,
>> of course, are the development work that goes into adding features and
>> fixing old bugs.
>> Now, in theory, we could have a release every quarter, but that would
>> mean we do only 1 month of feature work and 2 months of testing.
>> That, I think, would be very inefficient.
>> We could also drop our quality goals and do less testing.  Or ship
>> based on dates without any fixed test execution goals.  That would
>> allow us to release more frequently as well.
>> I don't think either kind of "compromise" is what our users really want.
>> IMHO, if we want to release more frequently then we need to find a way
>> to accomplish the same quality goals, but in less time.  So cut the 2
>> months of testing down to 1 months, or even less.  This could be done,
>> hypothetically, with more test automation and/or more test volunteers.
>> Also, a public beta or "bug finding contests" is not a substitute for
>> formal QA.  These things tend to be highly redundant, shallow feature
>> testing.  But they can be a good way to get early feedback.
>> Regards,
>> -Rob
>>> Virgil
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message