Yeah, any comments/commits/activity on a PR reset the threshold. e.g. https://github.com/apache/incubator-druid/pull/6768
On Thu, 28 Feb 2019 at 23:05, Gian Merlino <g...@apache.org> wrote: > I thought the bot uses a threshold of 60 days with absolutely no activity > (not 60 days since opening or anything like that); that does seem like a > long time to me for a PR to be totally silent. Especially considering the > bot won't close the PR right away, but will make a comment first asking if > anyone is still interested. > > On Thu, Feb 28, 2019 at 2:57 PM Roman Leventov <leventov...@gmail.com> > wrote: > > > IMO, 60 days is nothing in Druid terms. I suggest making it 6 months. > > > > On Thu, 28 Feb 2019 at 07:36, Dylan Wylie <dylanwy...@apache.org> wrote: > > > > > Infra got this switched on this morning for the repository, anyone who > > gets > > > email notifications would have unfortunately been spammed as the bot > > worked > > > through all our old PRs. This will likely happen again in 7 days when > it > > > closes all the PRs that remain inactive. > > > > > > For anyone wanting to clean up those mails the following search string > > > should take return all those mails in GMail for bulk operations > > > > > > "from:(stale[bot]) apache/incubator-druid" > > > > > > On Mon, 11 Feb 2019 at 22:15, Gian Merlino <g...@apache.org> wrote: > > > > > > > IMO it makes sense to keep PRs open if they have a milestone or have > a > > > > Security or Bug label. 60 days with no activity as a threshold sounds > > > good > > > > to me - it's a pretty long time. > > > > > > > > On Mon, Feb 11, 2019 at 11:22 AM Jihoon Son <jihoon...@apache.org> > > > wrote: > > > > > > > > > Hi Dylan, thank you for starting a discussion. > > > > > > > > > > I think this is a good idea. We currently have 159 open PRs, but > many > > > PRs > > > > > have gone too stale. For example, the earliest PR was opened on Jan > > 26, > > > > > 2016. > > > > > I do believe that this would help us to focus on more active PRs > and > > > > > encourage more people to get involved in the review process. > > > > > > > > > > The policy for the timeline looks good to me. But, for milestone, > we > > > can > > > > > assign it on any PRs and remove it later if it shouldn't block the > > > > release. > > > > > (See > > > > > > > > > > > > > > > > > > > > https://lists.apache.org/thread.html/371ffb06447debb93eec01863802aab13a08a9c37356466e6750c007@%3Cdev.druid.apache.org%3E > > > > > and > > > > > > > > > > > > > > > > > > > > https://lists.apache.org/thread.html/b9cd3aaf2d01801751f16ee0b2beb2cebc39e2a42160ffb268dc6918@%3Cdev.druid.apache.org%3E > > > > > for the discussion of the milestone policy). > > > > > > > > > > I think we should make bug PRs to be not auto-closed rather than > the > > > ones > > > > > assigned a milestone. > > > > > > > > > > Best, > > > > > Jihoon > > > > > > > > > > On Mon, Feb 11, 2019 at 8:27 AM Dylan Wylie <dylanwy...@apache.org > > > > > > wrote: > > > > > > > > > > > Hey folks, > > > > > > > > > > > > What are opinions on automatically closing old pull requests? > > > > > > > > > > > > There's a lot that our outdated and abandoned. I think some sort > of > > > > > > automated process will tidy away those that are truly abandoned > > while > > > > > > highlighting those that aren't by encouraging their authors to > poke > > > > > > committers for review. > > > > > > > > > > > > I've taken Apache Beam's stalebot configuration and adjusted it > > > > slightly > > > > > > here - https://github.com/apache/incubator-druid/pull/7031 > > > > > > > > > > > > This will: > > > > > > - Leave a comment and mark PRs as stale when they haven't had any > > > > > activity > > > > > > for 60 days. > > > > > > - After a further 7 days of no activity the PR will be closed. > > > > > > - Ignore any PR that has the label "Security" or a milestone > > > assigned. > > > > > > > > > > > > I've left issues out for now but open to suggestions on the > > timelines > > > > for > > > > > > those if we were to enact a similar process. > > > > > > > > > > > > Best regards, > > > > > > Dylan > > > > > > > > > > > > > > > > > > > > >
