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.
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 <cuyfa...@hotmail.com> 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: users-unsubscr...@openoffice.apache.org
For additional commands, e-mail: users-h...@openoffice.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@openoffice.apache.org
For additional commands, e-mail: users-h...@openoffice.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@openoffice.apache.org
For additional commands, e-mail: users-h...@openoffice.apache.org

Reply via email to