[JEG] [RESEND] Bug policy on deprecated (& removed) functionality

[jason.mcdonald at nokia.com]

> I think we need to define some kind of workflow/policy. I'm happy to
> start doing this on the wiki. Right now, I'd like to talk about bug
> lifetime for bugs reported on deprecated and removed functionality.
> The specific case I have in mind for now is QWS - it's gone in Qt 5,
> and I'm quite sure there are a lot of bugs reported on it.

There are a few components in the Qt project that are either obsolete already or headed that way when we stop supporting Qt 4.x -- EGL/Symbian, Maermo 5, mmfphonon (symbian), ODF Writer, Porting from Qt3 to Qt4, Smart Installer (Symbian), and the parts of Embedded that relate to QWS rather than QPA.

It would be nice if these stopped showing up in the component list when creating new bugs, but Jira doesn't seem to allow components to be hidden from that list, so they would have to be either deleted (which would strip that component from all existing tasks, even closed ones), moved to some kind of "Obsolete" project, or archived out of the system.

> I'd suggest that if functionality is removed:
> - all outstanding tasks/feature requests should be resolved as 'Out of scope'
> - if removed entirely, ditto for bugs
> - if moved to a 'qtmisc' or whatever module, bugs should be evaluated,
> P1s can stay open, everything else should be closed 'Out of scope'

Agreed.

There's always a lag between removing/deprecating something and being able to stop supporting it.  Historically, each Qt feature release has been supported until two more feature releases have been issued, e.g. 4.5.x support stopped when 4.7.0 was released.  Additionally, commercial customers occasionally negotiate contracts (with Digia rather than Nokia these days) to support old versions for even longer.

This means that bug reports may be accepted for a significant time after we stop accepting new feature requests for an obsolete component.

> for deprecated functionality, I'd suggest a slightly softer approach,
> whereby a shelf life is set on the reports. development@ should be
> informed of the deprecation, and if someone wants to volunteer to
> handle the issues to un-deprecate it (if applicable) they can do so
> and keep issues open, otherwise, close them as per the above policy
> after a 'grace period' of, say, two months.

At present we have a lot of components without a maintainer (see https://bugreports.qt-project.org/browse/QTBUG#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel).  For those components, all new reports go to Unassigned, from which they will probably never be further examined by anyone but me.

It is not easy for me, or anyone else, to see which of those components really are deprecated versus which are still important and seeking a maintainer.  It would be good if there was an obvious way to tell the difference.

> (to be clear: the reason for closing non-important issues on
> deprecated components is to remove the false hope that someone might
> actually fix them.

This would also make it easier to see which issues are really relevant when doing release planning (as I have been trying to do this past week).

> I would also suggest a template message being used
> for these cases being _very_ clear about the reason for the closing &
> giving the option for the reporter to take up maintenence of the
> component)

After the range of feedback I received last time I bulk-closed some old inactive tasks, I'll happily leave the task of producing the wording for such a template to someone who posesses some Marketing training and an abestos jumpsuit :-)

--
Jason