Simon Peyton Jones
simonpj at microsoft.com
Tue Apr 21 19:14:23 UTC 2015
GHC has a process for systematically downgrading inactive tickets. See
under "Re-milestoning after a release". Something like that might be useful for Cabal?
Mind you, I'm not sure that we have executed this algorithm following the 7.10 release (Austin NB).
| -----Original Message-----
| From: cabal-devel [mailto:cabal-devel-bounces at haskell.org] On Behalf Of
| Kosyrev Serge
| Sent: 21 April 2015 19:38
| To: Thomas Tuegel
| Cc: cabal-devel
| Subject: Re: inactive issues
| Thomas Tuegel <ttuegel at gmail.com> writes:
| > On Wed, Feb 25, 2015 at 1:53 PM, Thomas Tuegel <ttuegel at gmail.com>
| >> On Wed, Feb 25, 2015 at 12:21 PM, lennart spitzner
| >> <lsp at informatik.uni-kiel.de> wrote:
| >>> I am not convinced. how does closing ~40 out of ~700 open tickets
| >>> the contributors more effective? that demand exceeds resources is
| >>> true, but it is no argument for closing issues. many of the issues
| >>> represent sensible ideas for features that do not need new feedback.
| > At the risk of beating a dead horse, I just wanted to point out an
| > exchange on Twitter  which _proves_ that having a large number of
| > open tickets discourages our users from opening new issues when they
| > encounter bugs, even severe performance regressions.
| > I recommend, if you think there is any reason to believe an issue is
| > inactive, close it! We can always re-open issues if the re-occur.
| As a bystander and purely philosophically, the action of "closing" feels
| gratuitiously non-injective, since it conflates "inactivity" with
| Could it be that we could have a more discerning tracker, which would
| show the "not inactive" subset of "open" issues by default?
| Hardly so, with github, and yet..
| Косырев Серёга
| cabal-devel mailing list
| cabal-devel at haskell.org
More information about the cabal-devel