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


Hello

Just to answer very quickly to your message. While we don't really want to
keep comparing ourselves to AOO, because it's fruitless and does not focus
on gaining new users at all, I'm not too worried by the version numbering.
AOO 4.0 will have the Symphony interface, and what this means is that it
will bring a whole new different set of bugs. So my question would rather
be: is IBM ready to support users with bugs matching the OpenOffice.org
bugzilla reports and the Symphony bugs? That's a tough one, because AOO
might seem to be more conservative now -wait until they get their new
interface. Don't get me wrong, it's a good thing for everyone, as it will
bring clear product differentiation. But the support question will be
crucial and it's not being answered today.

As for TDF/LO not looking as professional compared to AOO, maybe it's a
matter of perception as you pointed out, but I think it's a meme that needs
to be killed, as it's been spread all over the place for ideological
reasons. This being said you will find 2 schools of thought here. One that
says that LTS style releases or less frequent releases provide more
stability and that more frequent releases provide more stability and
quality. OpenOffice.org (the old project) followed the former path and our
experience is that it was problematic and it often failed to deliver the
expected quality. Patches would wait one year, sometimes up to three years
to be included. TDF made the other choice. So far we're happy with it but
it does confuse a few professionals. I'm pointing out professionals here,
such as you, Marc, etc. Because users usually don't care, and service
providers with a larger size or linux distributions are usually very happy
with this model. I think the perception might be significantly changed when
we'll be able to provide incremental updates for each branch. Most of the
notion that our two branches create confusion or lack of readability will
fade away, we'll have two branches, one older ("LTS"???) and another one
which is more recent, and there will just be "updates". But  I am afraid
this mechanism might take longer than 6 months...

best,
Charles.

2012/6/6 webmaster-Kracked_P_P <webmaster@krackedpress.com>


If the last version of each line 3.4.6 and then 3.5.6 were kept in the
support loop for a bit longer than just a few months, that would help some
people.  I know each line keeps getting better and better, by the time the
.4 version is out, but I have been seeing references to AOO 4.0 as if they
will be skipping over the 3.6, 3.7, etc., etc..  So if people see the
original OOo version, now AOO, at 4.0 and LO is at 3.6 or 3.7, LO will look
behind them.

So we need to get people use to the fact that we are doing a different
version numbering, and we are also supporting our earlier lines for longer
than the 2 or 3 months it seems now.  I do not know how to really explain
my fears that people will start thing TDF/LO is not as professional as AOO
seems, or LO is not something business users should use but AOO is.

Also how many "normal" people would even get what a LTS version is all
about?

I do not think our developers should slow down the pace, but it does no
good to have a new version needing to be installed every month or two, if
business users will thing that LO is putting out buggy products just to
keep a release schedule.  MSO can get away with it, LO cannot.

We have been told that there will be a version/line in the future that
will not need to have a full install for every new version coming out, but
some "patch" release changing a .3 to a .4 version.  Hopefully that will
happen before the end of the year.  If not by then, hopefully it is as soon
as possible after that.  That will help all of us get business users to
except a rapid deployment schedule if all they have to do is install a
patch, like they now do with MSO.



On 06/05/2012 04:55 PM, Tom Davies wrote:

Hi :)
Thanks :)  I think that reinforces what Marc Pare is saying about needing
more than a month or so support.  Also it seems the overlap period will be
far greater, unless they switch to only doing LTSes every 4 years to be
more in-line with MS.
Regards from
Tom :)

--- On Tue, 5/6/12, Craig Olofson<c.olofson@gmail.com>  wrote:

From: Craig Olofson<c.olofson@gmail.com>
Subject: Re: [libreoffice-marketing] Re: Of "business ready use" and bugs
in LibreOffice and a LibreOffice LTS
To: marketing@global.libreoffice.**org <marketing@global.libreoffice.org>
Date: Tuesday, 5 June, 2012, 21:46

Fyi

Canonical changed LTS support for the desktop from 3 to 5 years, starting
with 12.04, to better accommodate their OEM customers.

 Normal Ubuntu releases are supported for 18 months. Previous Ubuntu LTS
(Long Term Support) releases are supported for 3 years on the desktop and 5
years on the server. Starting with Ubuntu 12.04 LTS, LTS releases will be
supported for 5 years on both the desktop and the server.

https://wiki.ubuntu.com/**Releases <https://wiki.ubuntu.com/Releases>

hth,
-Craig

On 06/05/2012 01:42 PM, Tom Davies wrote:

Hi :)
Ubuntu LTS lasts for 3 years (for desktops) but are released every 2
years.
This gives orgs the 1 year of testing they need before migrating from
the previous LTS and moving to the new one.  If they gave 3 years support
and released every 3 years then orgs would have a 1 year gap running an
unsupported LTS while they were still testing the new one.  Now i
understand why the 1 year overlap is so important to Ubuntu.
Regards from
Tom :)

--- On Tue, 5/6/12, Marc Paré<marc@marcpare.com>   wrote:

From: Marc Paré<marc@marcpare.com>
Subject: [libreoffice-marketing] Re: Of "business ready use" and bugs in
LibreOffice and a LibreOffice LTS
To: marketing@global.libreoffice.**org<marketing@global.libreoffice.org>
Date: Tuesday, 5 June, 2012, 21:23

Hi Charles,

Le 2012-06-05 09:12, Charles-H. Schulz a écrit :

Thank you for bringing that up, it's an interesting discussion. Here's
what I think reading your message. You're asking in fact two questions.
One of which might already have been answered by a few of our corporate
members/sponsors.
* LTS obviously means long term support. Both "support" and "long term"
      deserve careful consideration. I will in this email first focus on
      the term "support". If we speak of support, we must think of a
      support provider. In this case, does this mean we should think -as
      TDF, as a project- of providing professional support to users
      (obviously for a fee)? I don't think it's your idea, but I
thought I
      would highlight the implications of such a matter.
* Have we studied what some of the existing support/service providers
      on LibreOffice already offer? I am not so sure but I'm under the
      impression that you can order support (and in this case a "LTS"
kind
      of support) from Suse and Canonical (there are others) on one
      specific version of LibreOffice. That is, these vendors have one
      reference version of LibreOffice, say the 3.4.5, and they provide
      support and services on it making it their de facto LTS version.

Yes, this is fine as they will guarantee that LibreNormal Ubuntu
releases are supported for 18 months. Previous Ubuntu LTS
(Long Term Support) releases are supported for 3 years on the desktop
and 5 years on the server.  Starting with Ubuntu 12.04 LTS, LTS releases
   will be supported for 5 years on both the desktop and the server.
Office will work on their systems and they will take care of any
dependencies and network-ability. But I don't think they would undertake
any code revision and code features into their LTS versions, not unless
they have a large team of coders, which in this case would make them
"competitors" to our work/product (read "fork"). This would take us back to
the days of the many different versions of OOo -- the same situation that
drew all of these different groups into one LibreOffice community.

Leaving support/service providers to develop an LTS version, in my
opinion, is not the right strategy to adopt.

 Back to your suggestion: do you mean we should relabel the older branch
"LTS", knowing that each of our releases in one branch really works
like a "service pack"? If we had the ability to provide incremental
updates (we will one day) we would have the feelings we have two
versions, and sometimes "maintenance updates". So at some point, say
the 3.5.4, we label it LTS, because we're close to open a new branch,
the 3.6, and we can suggest service providers to base their support
offers on this one for the time being. Did I get you right?

No. I suggest that at some point, the TDF/LibreOffice should designate
an LTS version for large/small organizations/businesses. These would have
developers oversee the fixing of bugs for a fixed term (let's say a 3 year
period) after which time another LTS version would be designated. The LTS
maintenance would NOT introduce any new functions to the distro but only
service bug correction. IMO, if any business entity would like to add any
new functionality, then this is where a support/service provider would step
in and, hopefully, contribute any development of code back to the community.

I don't really think this is a new concept as even Mozilla-Firefox
offers its own "Extended Support Release (ESR)" version for corporate
users[1]. When critical software packages are installed in large
corporations, a lot of energy in investment of time, training and
documentation is expended in order to get employees up to speed.
LibreOffice certainly falls into this category (critical software --
wordprocessing software). While Firefox ESR is being released initially for
a period of approximately 1 year, IMO, I believe they will ultimately find
that a longer term will be necessary for these large organizations. As for
a version of LibreOffice LTS (or ESR), the impact of change for large
organizations is even larger due to the amount of training of staff of new
features (even more so in the educational field with the training of
younger students).

If we are looking to supplant MSO in the office place, we need to
realize and accept the simple fact that the amount of software/network
testing as well as (and even more importantly) the training of staff for
large orgainizations is considerable. I sincerely doubt that a "one
year"-term LTS for LibreOffice would suffice; one year is just about enough
time to test out the suite before it is even installed; most organizations
simply do not have the manpower to move any quicker.

If we wish to compete in the large business market place we need to plan
and develop more strategically with our releases. Developing an LTS version
will fix this. Otherwise, the choice will remain MSO for office use, where
MSO has a longer term of support with incremental changes for bugfixes and
where LibreOffice will remain marginalized as an office suite.

 Best,

-- Charles-H. Schulz Co-founder&   Director, The Document Foundation,
Zimmerstr. 69, 10117 Berlin, Germany Rechtsfähige Stiftung des
bürgerlichen Rechts Legal details:
http://www.documentfoundation.**org/imprint<http://www.documentfoundation.org/imprint>Mobile 
Number: +33 (0)6 98 65
54 24.

Cheers,

Marc

[1] https://wiki.mozilla.org/**Enterprise/Firefox/**
ExtendedSupport:Proposal#**Benefits<https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal#Benefits>


-- Unsubscribe instructions: E-mail to marketing+help@global.**
libreoffice.org <marketing%2Bhelp@global.libreoffice.org>
Problems? http://www.libreoffice.org/**get-help/mailing-lists/how-to-**
unsubscribe/<http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/>
Posting guidelines + more: http://wiki.**documentfoundation.org/**
Netiquette <http://wiki.documentfoundation.org/Netiquette>
List archive: 
http://listarchives.**libreoffice.org/global/**marketing/<http://listarchives.libreoffice.org/global/marketing/>
All messages sent to this list will be publicly archived and cannot be
deleted


-- Unsubscribe instructions: E-mail to marketing+help@global.**
libreoffice.org <marketing%2Bhelp@global.libreoffice.org>
Problems? http://www.libreoffice.org/**get-help/mailing-lists/how-to-**
unsubscribe/<http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/>
Posting guidelines + more: http://wiki.**documentfoundation.org/**
Netiquette <http://wiki.documentfoundation.org/Netiquette>
List archive: 
http://listarchives.**libreoffice.org/global/**marketing/<http://listarchives.libreoffice.org/global/marketing/>
All messages sent to this list will be publicly archived and cannot be
deleted




--
Unsubscribe instructions: E-mail to marketing+help@global.**
libreoffice.org <marketing%2Bhelp@global.libreoffice.org>
Problems? http://www.libreoffice.org/**get-help/mailing-lists/how-to-**
unsubscribe/<http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/>
Posting guidelines + more: http://wiki.**documentfoundation.org/**
Netiquette <http://wiki.documentfoundation.org/Netiquette>
List archive: 
http://listarchives.**libreoffice.org/global/**marketing/<http://listarchives.libreoffice.org/global/marketing/>
All messages sent to this list will be publicly archived and cannot be
deleted



-- 
Unsubscribe instructions: E-mail to marketing+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/marketing/
All messages sent to this list will be publicly archived and cannot be deleted

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.