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

[Jean-Baptiste Faure]

Hi,

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
upgrading.

> 
> 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 4.0.2.2. I think the rc digit is confusing for
endusers and useful only at development stage.

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