Tim, Marc, To be sure: we all want to have such an incremental upgrade mechanism. We all know it' s a real PITA, devs, qa testers, localizers, etc. We have inherited from a very problematic codebase and things do not happen overnight. But I am confident they will happen.
Best, Charles. Le 6 juin 2012 18:39, "webmaster-Kracked_P_P" <[email protected]> a écrit : > On 06/06/2012 11:28 AM, Charles-H.Schulz wrote: > >> 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. >> > MSO is still on 2010 version, but they patch it - whenever they choose. > So some would say MSO is using a LTS model. > > For me, I would love it when the patch process model for LO is worked out. > Then we will not need to have the issues of reinstalling a full version > every few months. > > As for LTS, well as I stated before, one we get to the last version of a > line, it would be nice to have a bug fix or two for that one while we wait > for the last version of the current line. That might be a step towards the > LTS model. There could be a 3.5.6.a/b or 3.5.6.1/2 for a bug fix release > while people can work out all the issues for the 3.6.x line. Then the > process starts over again with the 3.6 vs. 3.7 lines. > > Would there be any support for doing a bug fix for a .6 version while > working on the .3 or .4 version of the next line? > > For businesses it might work. > > But the real need would be getting a patch cycle work out. But it takes a > lot of extra work to do a patch cycle than it does to what is done now. > With installing all the .deb files, it might be easier than it would be to > patch a Windows version. But it still would be a harder process than the > current release model. > > Currently, how many individual files must be compiled for a total release > for all OS versions? How many .deb files are in the 64-bit version that > must be installed with "dpkg"? Each one of them has to be compiled/make[d] > individually - right? > > I do not want to think about what is needed to be done to change to a > patch cycle model that would go along with a LTS release model. > > As Marc and others have stated, it takes a lot of IT time to test and > deploy a package for a 50+ user business/school/agency. They would not be > able to do this for every version or even every second or third version of > a LO line. SO there may need to be some type of LTS model in place to > encourage them to use LO. Even if it is just sticking with the .6 versions. > > But, TDF/LO will need to do something to make it more business-friendly as > in the case of release cycle patching or LTS release cycle. The better LO > can be marketed to their support needs, as well as the features they need, > the more business users we get and hopefully the better it will look as a > market contender - inside and outside the open source community/market. > > -- > Unsubscribe instructions: E-mail to marketing+help@global.** > libreoffice.org <marketing%[email protected]> > 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 [email protected] 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
