Hello Marc,
Le mercredi 06 juin 2012 à 11:04 -0400, Marc Paré a écrit :
Le 2012-06-06 06:12, Charles-H. Schulz a écrit :
Interesting ideas here... I wonder how we could plot this with respect to
our existing resources. The key issue here is resources . LTS only makes
sense if you derive revenue from it.I think we could relabel one branch as
LTS, the older one if it brings more clarity. It will work for one year. I
don' think working on a branch for 5 years makes sense for a FOSS project,
as -again- the examples pointed out stem from commercial offerings (even
Mozilla with all its resources only provide a one year support and
Canonical or Red Hat offer paid-for support for customers paying each year))
Not necessarily. An LTS version is by name only that: "a long term
support version" and does not in itself bring on any connotation of any
revenue generation for LibreOffice nor any other software company.
Imagine all of our large-scale installations that are now occurring in
the EU and BR. When they find out that they will have to change on a
more frequent basis to keep up with bug fixes (our present model will
only bug-fix for only the previous version and not any versions prior to
this); at some point, there will be some sort of rationalization of
their use of their large-scale LibreOffice installation and their TCO
(total cost of ownership). If there are any other office suites (MSO,
AOO) that offer any product with LTS (you may call it whatever you wish,
ESR-extended support release ...), then, the cost related to continual
update/upgrade-testing will put LibreOffice at a clear disadvantage over
any LTS-version-office-suite. I cannot imagine a government entity or
large institution/business opting for costly installation/retraining
costs ad infinitum ... there will eventually be a breaking point and the
loss will be ours to bear.
I see your point, but perhaps my answer will sound pessimistic: even
with a LTS version things will not improve. The reason is simple: there
are two different issues that are mixed: one is the incremental update
and the other one is the support duration of a version.
Let's say we have a LTS version as you propose. Let's say we commit to 5
years of support(!!!). How do security fixes and other patches get
pushed to this version?
Today, it's done by... redownloading a ful version of LibreOffice. So
today it makes sense, after one organization has deployed, say, 3.x.3
to migrate to a 3.x.4 because that's where the patches will be anyway.
Today we cannot patch a version and send the update over to one
instance. I think that's the real crux of the problem. Otherwise, we
would say, in a month or so: "the 3.5 (note the numbering here) is our
LTS release". And anything that would need to be patched would be
patched incrementally. No need to redownload another version of
LibreOffice. Basically what I'm saying is that -while I think the LTS is
mostly a business issue because it requires a lot of resources to
produce and maintain a LTS- until we have an incremental updates
mechansim, our present discussion is not moot, but close to it. Because
we're stuck in a situation where the only thing we could say is: "get
this version (say, the 3.5.4), it's very stable. If you need updates,
we'll have to redeploy". And there's really no other way to go about it,
and it's the same for AOO btw.
Best,
Charles.
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.