lucf117 has quit [Remote host closed the connection]
AdamGordonBell[m has quit [Quit: node-irc says goodbye]
<headius>
good morning!
<basshelal[m]>
good morning
<headius>
taking a moment to check our pass rates on JDK16 since that release made illegal access "deny" by default
<headius>
so far looks fine
<basshelal[m]>
I tried to move JFFI to JUnit5 but that was embarrassing, might be hard for me but might not even be as useful since it's more C than Java anyway
<basshelal[m]>
JNR-POSIX is tricky too I think but I'm a little exhausted for it
<headius>
yeah the jffi stuff is a little more involved
<basshelal[m]>
I posted a new issue on JNR-FFI regarding a benchmarking suite, let me know what you think
<headius>
any at all really but I was running spec"ruby"fast
<headius>
::
<enebo[m]>
yeah. running now
<headius>
ok something is screwed up here then
<enebo[m]>
I thought someone said something about later Javas and ant not working but this would not appear to be that
<headius>
I think I found it
<headius>
I had a rogue ant.jar in lib/ probably from my experiments trying to fully modularize
<headius>
so it was loading that instead of the ext
<headius>
might need to scrub this env soon
<headius>
I wanted to push a PR that enables some suites on JDK16 since that one denies all illegal access by default
<headius>
good to know before release that things pass the same on 16 as they do currently on 14
<headius>
I pushed 14 to 16 move for travis which should be basically a no-op, but I will also add JDK16 runs to GHA
<enebo[m]>
cool
<headius>
there were a couple other tweaks for that MacOS no-JAVA_HOME thing last night but it should be fixed everywhere now
<headius>
pushed a new launcher with the change
<headius>
windows could use a new exe but it did not touch any windows code paths
<headius>
hmmm the GHA builds will be a problem because the Ruby plugins still run with an old version of JRuby that does not behave well
<headius>
seems to be failing booting up some of the dist testing stuff
<headius>
I think I will punt on the GHA builds until 9.3 is out, so we can move the plugins to that release
<headius>
not sure how else to make it work other than running maven with a bunch of module flags that might taint results
<headius>
enebo: we should start talking about what remaining items to push to 9.3.1 so we can get this thing 9.3 out by end of July
<headius>
like getting down to just critical items: autoload regression, memory/stack problems in JI
<headius>
or rather perhaps we should be talking about minimum remaining work to get 9.3 out
<headius>
we know it will require many update releases once people actually start testing it anywa
<headius>
enebo: I told that DirkMahler to do the JarCache improvements on 9.2 since that will be the one asciidoctor and other key embedders use for quite a while still
<enebo[m]>
headius: yeah looking through the last 54 issues most of them seem puntable to me. I will fix the case/when logic. There is some coverageish stuff we are really lacking on but that is partially a problem since 2.5
<headius>
yeah punt away
<headius>
9.3.1 or 9.4 for stretch goals
<headius>
coverage would be a good 9.3.1 job
<headius>
or 9.3.x
<headius>
we have only gotten a few reports about it so I am not sure how heavily it is used
<enebo[m]>
You may want to take a pass over these and mark milestones on this class of issues that you opened
<headius>
ok
<headius>
pretty much all of my would be nice will be 9.4
<headius>
enebo: I did a first pass for 9.4 moves, down to 43 open
<headius>
we need to review PRs also... there are some nice to haves and a bunch of stale red PRs
<headius>
you have one for nanosecond time for example that is green
<headius>
enebo: I will punt all coverage related stuff to 9.3.1
<headius>
that requires work from both your end and mine so it clearly won't happen for .0 but we might be able to get it working before 9.4
<enebo[m]>
sure I think 9.4 is fine for it since I barely even remember what it is and I have had doubts about it ever since :)
<headius>
mostly things like branch and code block coverage etc
<headius>
just finer-grained tracking, not sure what is different in CRuby to support that tracking
<enebo[m]>
those for sure I don't think are needed we can put in notes we plan on working on them later
<enebo[m]>
release notes on what is not there
<enebo[m]>
When I started looking at those two issues I could see we may need more metadata about code than what we are capturing to know it is in a method or a block or whatnot
<enebo[m]>
branching I did not even think about
<headius>
down to 33 open I want to review in detail
<headius>
14 PRs
<headius>
enebo: I'm moving on to triaging the remaining 9.3 items to see what is still an issue and what can be punted and what needs to be finished
<enebo[m]>
ok
<headius>
kares: I have noticed after some partial builds locally, like just doing 'mvn', lib/ruby/stdlib/rubygems.rb gets wiped out
<headius>
not sure why that is or if it is just my env but could your logic to install rubygems at build time cause this
<headius>
?
<headius>
a clean rebuild fixes it but not sure why this file disappears