[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reducing the number of open issues

From: Jonas Hahnfeld
Subject: Re: Reducing the number of open issues
Date: Sat, 20 Mar 2021 11:00:04 +0100
User-agent: Evolution 3.38.4

Am Freitag, dem 19.03.2021 um 23:58 +0100 schrieb Jean Abou Samra:
> Le 17/03/2021 à 20:10, Jonas Hahnfeld a écrit :
> > Hi all,
> > 
> > there are currently 1066 open issues at LilyPond's GitLab repository:
> >
> > 
> > I'd like to reduce this number: In the short term, I propose to close
> > issues with ~Patch::abandoned (69 open issues) and ~Patch::needs_work
> > (73 open issues) labels that come from patch tracking with SourceForge.
> > They will stay around (including their links to Rietveld, as long as it
> > stays alive), but not artificially increase the number of "issues".
> > The caveat is that I remember some real problem reports with proposed
> > patches, that were abandoned during review. I'll keep those issues open
> > because they might need fixing either way.
> > 
> > Any objections to this plan?
> Agreed, I think it makes no sense to keep these issues
> open. I would guess that in nearly all cases, it's
> better to start fresh patches. If you're willing to
> put in the effort to start new issues when the old
> patch-tracking ones indicate a bug, I'm all for it.

No, that's exactly *not* the plan: Bug reports should remain open
because the context is important. I see no point in closing existing
reports just to open a new one without the history (and I've advocated
against this practice in the past).

I had hoped this to be clear ("keep [...] open"), but let me give some
examples: can be
closed as it was a contribution picked up from the mailing list
) where the review comments were not addressed.
On the other hand, I'm certainly not going to close the famous
For both of them, I'll leave the ~Patch::abandoned label because that
provides information and an easy way to find such issues later on (even
if closed).


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]