Re: [Libreoffice] Preparing announcement of the 3.4.2 release

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