openoffice-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scooter <>
Subject Re: AOO-Members dont forget voting
Date Sat, 20 Jul 2013 19:22:38 GMT
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?
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.
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:

View raw message