curl / Mailing Lists / curl-library / Single Mail


Re: Closing idle issues and pull-requests

From: Daniel Stenberg <>
Date: Fri, 21 Apr 2017 15:50:31 +0200 (CEST)

On Fri, 21 Apr 2017, Michael Felt wrote:

> As far as 90/14 days - what is your bigger concern? That something gets lost
> (removed) prematurely, or that it hangs around "too" long, before someone
> gets back to it.

My biggest concern is that some people will find it rude that their issue gets
closed, which is why I want to make sure the issue is truly stale before
taking that step. But at the same time I want to filter out the "unimportant"
ones (as stale issues signal to me that they're not the important ones).

But for clarity: we made it 180/14 days in the config that is now active.
Exactly ten issues have been marked stale because of this so far.

> If this is only for "stale" pull-requests - may be fine, as the original
> author (pull-requestor) should still have their files. However, I know
> myself - I have days when I can look at git-related projects and/or
> respond/write to a mailing lists and then months where work prevents me from
> continued involvement.

It is for both issues and pull-requests. But no information is deleted or
removed with a close so there's really no data-loss risk because of this. All
of them can be re-opened just as easily as it was closed and it is also easy
to create new issues.

> Lastly - assuming the bot sends mail to "all" who have commented on a
> pull-request, 14 days may be a bit short. Just my luck - I go on vacation
> for 21 days and the bot sends mail I do not see for 19 days... imho: 14 days
> is cutting it tight.

Sure, I realize that, but first you need to leave it untouched for 180 days so
why does 14, 21 or 28 days matter much after that long time? If the issue is
important (to anyone) it really should not go stale that long. I don't think
that final 14 days period will risk too many issues getting prematurely
closed. And for the occasional ones that still do, we can just re-open them
and add the new info.

Received on 2017-04-21