Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Caolán McNamara wrote (26-07-11 10:57)
On Tue, 2011-07-26 at 00:10 +0200, Cor Nouws wrote:

Caolán McNamara wrote (25-07-11 13:27)
On Mon, 2011-07-25 at 02:18 +0200, Cor Nouws wrote:
      Still, there are some issues that I would have to advice my
customers about (in my work providing professional support for
enterprises), since they could have effect on their specific work.

If you wish to have a "enterprise-ready" or "enterprise-ready" concept,
you then need to have an objective set of criteria that defines what
that is. A check-list of features, bugs, or something. Ideally something
which could then be coded into a automated regression test, and make the
whole thing completely moot by cutting off at the knees the possibility
of regression/changes happening of becoming non-enterprise ready.

Sounds interesting to have that, but would very difficult too: what to
include, and what not, etc etc.

My point is just that; I don't know where the "enterprise-ready" term
wandered in as a meme,

As explained in my initial mail, the term came up in the discussion around the 3.4.0 release. Since we say that a point-zero release definitely is not to be used in enterprise environments, that also hold the expectation that we can advise a later version as such.

and if it is to be used as an argument for
release blocking, schedule changes, criteria for release, argument for
defining one version as stable and another not, etc. then surely it has
to be accompanied by an objective test.

If you see it as exact science: yes. But I do not see labelling a version as 'enterprise ready' as that.

The smoketest.sxw macro using test is a possible model for scripting up
some high-level test cases, e.g. there's been a bit of foo around mail
merge. It should be possible without any super-dooper development
knowledge to knock up a mail merge (non-email) test based on the basic
database smoketest section of that. That'd give an objective "enterprise
mail-merge requirements pass" test for example.

   Well, that should be attractive for part of the users at least!

   From the open issues in #35673, IMO some should be looked at (*)  by
enterprises, when preparing the upgrade, though some of them are present
in 3.3.x too, I guess. Will try to have a closer look at that last point
(3.3.x<>  3.4.x) tomorrow (or the day after). But can only do that on
Ubuntu, not on Mac or Windows...

Regards,
Cor

*) I would advise data-source connection plus mail merge in general,
plus 36631, 39447, 37015, 37024, 37030, 37487, 37620. 38542, 38595, 38745.

There's the tangled-up concept of blessing 3.3.X as enterprise-ready and
3.4.X as not. So if an above bug exist in 3.3.X as well as 3.4.Y, then
it presumably isn't relevant as a basis in selecting one LibreOffice
version over another or as a blocking criteria for the next version,
right ?.

   Yes, that is the logic behind it.
The other side is, that 3.4.x offers much new and improvements to, that can well outweigh then some particular 3.4 bugs. And since that can easily be an individual choice, it can never be exact science drawing a sharp line. But based on current information, I would say 3.4.2 can be considered by most enterprise users.

Regards,

--
 - Cor
 - http://nl.libreoffice.org


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.