Maybe we should bring this to the dev mailing list but I am thinking about suggesting the use of https://github.com/actions/stale

We could add a long time like 1yr. If there’s no activity in an issue or PR after a year, is there a point in keeping it open?

Closing it doesn’t makes us lose it while giving focus on current issues at hand.

For organization purposes I was going to suggest we mark every new issue as triage and have one of us triage the bug and re-tag it appropriately.

There are lots of old bugs that are still bugs

And I don’t want to close any pull requests automatically

Fair enough - although the danger is that the number of issues / prs will grow and we’ll never have enough hands on deck to deal with them. At around beginning of 2019, if my mind serves me correctly the number of open issues was under 200. We are almost hitting 400. That’s in about 14 months.

Right, it’s an issue (so to speak)

But we need to do more triage

And it’s not so many that we can’t get caught up first

Or we host issue marathons to improve the situation. :slightly_smiling_face:

Yes, I want to do that

Certainly more triage would help. :

I will try to suggest a time that we can do one

Sounds good.

Please suggest a catchy name… :wink:

“The Great Racket Issue Purge”

or something like that… :slightly_smiling_face:

One detail that might be worth keeping in mind which i just noticed.

The repository will be downloaded using the GitHub REST API To create a local Git repository instead, add Git 2.18 or higher to the PATH

That’s from the checkout action.

If git is not in PATH, the checkout action fetches the repo using the github api and does not create a git repo.

This might be important in some cases. I noticed this because I ran on an action git clean -xdf and it said it was not a valid repository.

https://github.com/racket/racket/runs/645900636?check_suite_focus=true#step:3:17

Just to make sure, you are aware of this error, correct?

[2020-05-05T09:58:06] The server time is now Tuesday, May 5th, 2020 9:58:06am /bin/sh -c if [ ! -d "cs_build" ] ; then git clone "<http://localhost:9440/.git>" "cs_build" ; fi Cloning into 'cs_build'... error: Unable to find f57aa0b90f17f386b80c675c57521cab71eb1645 under <http://localhost:9440/.git> Cannot obtain needed commit f57aa0b90f17f386b80c675c57521cab71eb1645 while processing commit 65a1aa9cb323f16deb5bdba47eece997d60d0e41. error: fetch failed.

yes, trying to fix it

although I don’t totally understand why it happens

@pocmatos sorry, not all false positives, but the actual bugs (not leaks or dead code) were false positives

or in LZ4

OK - I will take a look. We can configure the analyser to avoid those. It would be great to get RacketCS down to zero. :slightly_smiling_face:

first 3 are in lz4

then there are 6 dead stores

then there’s one potential division by 0 that’s very hard for me to figure out because of lots of fancy C macros

then there are a bunch of leaks

the first 2 leaks are leaked and then racket exits

the next one is not a real leak because putenv keeps the memory

then another exit

then another putenv

then it claims that we’re leaking argv[0]

thanks for the analysis, i will take a look

then a not-real leak because getcwd is awful

i put it all here: http://html.sice.indiana.edu/~samth/2020-05-05-120225-8584-1/

and then finally a leak that says it’s about p but really we may be leaking path but I’m not sure

Thanks - keep it there if you can. Just having a work emergency… JavaScriptCore playing up on mips! :slightly_smiling_face:

@samth how did you compile the racket you gave to igouy from #3150 so that it’s now generating a log message? Did you enable some internal logging?