Auto-expiring bugs are getting absurd

[Jaroslav Reznik]

----- Original Message -----
> On Fri, 2014-02-07 at 04:26 -0500, Matthew Miller wrote:
> > On Thu, Feb 06, 2014 at 11:54:30PM -0800, Adam Williamson wrote:
> > > > What is the underlying problem here anyway?
> > > I've never been hugely convinced there is one, but the problem people
> > > *claim* there is is that closing bugs on EOL releases gives a bad
> > > impression to people who report the bugs.
> > 
> > We're terrible at numbers, but subjectively, people complain to me about
> > this at conferences a lot.
> > 
> > > Why do you think they're any more likely to get a response if the bug
> > > stays open?
> > 
> > Here's one case: a relatively stable package where there are small RFE
> > bugs,
> > or spelling fixes, or packaging improvements which are clearly right but
> > have low practical impact.
> 
> There is a kind of magic trick for this: if you set a bug to be against
> Rawhide and give it the FutureFeature keyword (which is our 'official
> way' of identifying RFEs), it won't ever be re-based to a stable release
> at Branch time, and hence won't ever get EOLed. That's a bit secret
> sauce-y, though.

It's a bit more hidden, right. I try to communicate during Rawhide rebase,
but adjusting EOL warning is not a bad idea at all.

Jaroslav