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

Robin Burchell robin+qt at viroteck.net
Fri Mar 30 12:11:47 CEST 2012


Hi,

(resending, since I got no feedback last time :-P)

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.

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'

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.

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

Comments? Suggestions?


More information about the JEG mailing list