[Libreoffice-qa] After EOL has been reached...

Jean-Baptiste Faure jbf.faure at sud-ouest.org
Sat Apr 27 01:00:08 PDT 2013


Le 26/04/2013 11:24, Bjoern Michaelsen a écrit :
> Hi,
> On Fri, Apr 26, 2013 at 09:47:28AM +0200, Jean-Baptiste Faure wrote:
>> Le 19/04/2013 23:21, Robinson Tryon a écrit :
>>> Per discussion at the meeting today, we generally agreed to the following:
>>> AGREED: For users inquiring about tech support after the EOL date of a
>>> release, we politely indicate that the release is EOL and ask them to
>>> upgrade to a new version (or go talk to their vendor/distro/paid tech
>>> support)
>> What do you mean by "users inquiring about tech support" ?
>> Who is "we" here ? I think that subscribers of users mailing lists do
>> what they want and answer the questions they want.
> The user list does not provide tech support, though ;). This is about people
> complaining about bugs not getting a bugfix in an ancient and unsupported
> version of LibreOffice. If someone is using LibreOffice 3.5.x and reports a
> bug, it will not get fixed on 3.5 unless he has a support contractor of some
> kind that is able to provide him with a custom build. Note that this is
> invincible in principle as TDF will not release any further versions of 3.5.x.
> I think its good to make reporters aware of that.

Ok, I see. Is there many requests in bugzilla asking for a backport of
some fix to an old unsupported version?
French public administration has the problem with LO 3.5.7 which is
solved by paid support.
>>> AGREED: We de-list versions in Bugzilla 6 months after the release has
>>> been EOLed
>> I do not see any rationale for that.
>> What I suggest is to remove all RC and beta version from BugZilla as
>> soon as the corresponding final version has been published.
> Hmm, sounds like a good idea too. If someone triages it even further (e.g. a
> bug was not there in 3.6.2 rc1 but is in the final version), a comment in the
> bug might suffice. While the info is highly valuable to a developer trying to
> fix the bug (in which case a reading of comments happens anyway), it is not
> something we can query bugzilla for esp. since the version we set in bugzilla
> is the earliest _known_ version to have the bug. So a bug reported against
> 3.6.2 rc1 can just as well have already been there in 3.6.1 final.

Yes, and if a user is able to install LO and to decide the version he
want to use, he should install the final release and try again before
reporting a bug against an old RC.
And if a user has not the power to decide the version to use, then his
sysadmin must install only final versions and this user doesn't need to
report bugs against RC.

> That being said, I expect most regressions in a minor update (4.0.2->4.0.3) to
> be in the RC1 already, and most regressions in a major update (4.0.x->4.1.x) to
> be in the beta already anyway.
>> You know, we have users who work with LO 3.3.x and others who plan to
>> upgrade to LO 3.5.7 at the end of this year ... They don't decide for
>> themselves.
> Well, they are running unsupported versions of LibreOffice. For these reports
> to be interesting for the LibreOffice project at least the following has to be
> true: The bug has to be reproducable in a supported version of LibreOffice.

Yes indeed. And with my hat of end-user helper, if the bug is not
reproducible in current release, I can use it as an argument to suggest

> Note that the reduction of the numbers of versions to select from is valuable
> in itself. I find myself being annoyed by scrolling through that long list in a
> small box, and imagine it is even more irritating to e.g. a first time bug reporter.

I agree. In my fdo configuration, or in BSA, I see the newest version
number first in the dropdown list. It isn't the default case?

That said, I guess we can remove the rc number for stable release and
show 4.0.2 instead of I think the rc digit is confusing for
endusers and useful only at development stage.

Best regards.
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.

More information about the Libreoffice-qa mailing list