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

[Bjoern Michaelsen]

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.

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

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.

If you have a bug in 3.5.x and its fixed in 3.6.x everything is fine from the
perspective of the LibreOffice project. If you want a fix for 3.5 you need a
custom build from a support partner (or do the fix yourself: this is open
source).

We could consider leaving in the latest version of each major series (e.g.
3.5.7, 3.4.6), even if unsupported to keep it easy to mark a bug a being around
for longer.  Note however that even this actually _lowers_ the priority of a
bug anyway: If something is a recent regression (e.g. broken in 4.0, worked in
3.6) it has priority over something that is broken since the dawn of time.

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.

Best,

Bjoern