20:34 <travis-ci> jruby/jruby (no_sourceposition:c64c698 by Thomas E. Enebo): The build is still failing. https://travis-ci.org/jruby/jruby/builds/687177089 [146 min 8 sec]

20:40 <headius[m]> valphilnagel: hey we keep missing each other

20:40 <headius[m]> valphilnagel: if you have some tweaks that can get this working on both, please look at a fork + PR!

20:41 <headius[m]> plus a PR or issue will get conversation going... have you opened anything so far?

20:41 <headius[m]> I'm glad you're making progress and yes I think we should even favor OpenJFX since that's the path forward

21:20 <enebo[m]> lopex: how are you buddy?

21:28 <cpuguy83> @headius[m] So for the docker-jruby repo, I invited you as a collab so you could transfer it to the jruby org.

21:29 <cpuguy83> I did try to transfer it myself, but said I couldn't create a new repo in the jruby org.

21:29 <headius[m]> cpuguy83: yeah I don't know how to give you just that permission... I can only make you an admin

21:29 <headius[m]> but it occurred to me that it's better to just leave it there for the moment

21:30 <cpuguy83> I think one thing tianon liked is having the issue/PR history in tact.

21:30 <headius[m]> I don't seem to be able to get to the settings for the repo so I'm pretty sure I have to be admin on your org too

21:30 <headius[m]> it's not a permission that's easy to give out alone

21:30 <headius[m]> oh yeah we won't re-push in any case... it will maintain your history

21:31 <headius[m]> I have no Settings tab on cpuguy83/docker-jruby

21:31 <cpuguy83> Hmm yeah, it seems only collaborator is possible.

21:31 <headius[m]> by re-push I mean we won't take current revision and make it revision zero

21:31 <headius[m]> we could repush as non-fork but it doesn't matter... it won't be a fork once your repo goes away

21:32 <cpuguy83> That works. I guess the next step is to update https://github.com/docker-library/official-images/blob/master/library/jruby with the new repo and maintainer

21:33 <headius[m]> enebo: I nominate you

21:33 <enebo[m]> bleh

21:34 <cpuguy83> haha

21:34 <headius[m]> in the short term I suppose it can be either of us so we can start the transitioning

21:34 <enebo[m]> well I guess it needs to be done

21:35 <headius[m]> we have had some soft commitments to help but someone core to the project should still own it

21:35 <travis-ci> jruby/jruby (no_sourceposition:71247c4 by Thomas E. Enebo): The build is still failing. https://travis-ci.org/jruby/jruby/builds/687199119 [139 min 15 sec]

21:35 <headius[m]> once we get some contributions from users maybe a new maintainer will rise to the top

21:35 <enebo[m]> bleh

21:46 <cpuguy83> Sorry to throw more work your way :(

21:48 <enebo[m]> cpuguy83: so I believe we run a command with the Dockerfile we have and it generates bits and signs it or something like that and then pushes to docker mother ship?

21:49 <enebo[m]> cpuguy83: and if we need to support 8 and 13 we would do this twice with a slightly different Dockerfile?

21:49 <cpuguy83> @enebo[m] The docker mother ship builds it, this is just the spec.

21:49 <enebo[m]> or possibly some ENV when running the dockerfile

21:49 <headius[m]> cpuguy83: I'm hoping this isn't a lot of work once we have things configured

21:49 <headius[m]> and we would just include it as another release artifact

21:49 <enebo[m]> cpuguy83: ah so we push the spec somewhere and it does the rest

21:50 <cpuguy83> Yep.

21:50 <headius[m]> and that's what's in your repo

21:50 <enebo[m]> ok and how do we verify that it successfully completed?

21:50 <headius[m]> cpuguy83: apologies for losing your description of the process, we are new at this

21:50 <enebo[m]> the tangential question is also how long does it tend to take

21:51 <headius[m]> but it's time to address it

21:51 <cpuguy83> So really it's just keeping up with jruby and jvm releases. From there the community may want changes from time to time... actually there's some changes from the MRI ruby image that might need to get made for jruby just for consistency if nothing else.

21:51 <enebo[m]> yeah we really don't know much about docker. I have used it locally for multiple db instances but not much more than configing as a consumer

21:51 <headius[m]> right we keep getting more requests for an image with updated JDK

21:51 <headius[m]> trying to figure out the best way to do that without permuting all JRuby and JDK versions

21:51 <headius[m]> SBT seems to be doing something different here? https://hub.docker.com/r/hseeberger/scala-sbt/

21:52 <cpuguy83> @enebo[m] When you PR the spec changes there's some sanity checks that are made. The team that reviews it is also quite thorough in checking things. I'm not sure in what timing the images are actually updated.

21:52 <enebo[m]> So our release requirements are our version and any u-updates on JVM

21:52 <headius[m]> I guess this is just a way to build on the fly with a different "from" for your needs?

21:52 <enebo[m]> cpuguy83: ok so far from real time was one answer :P

21:52 <cpuguy83> And there's also automatic image updates that happens due to bugs or cve's in the base images.... nothing to do for this, it just happens.

21:52 <enebo[m]> cpuguy83: ah that is super nice

21:53 <headius[m]> so once we have a recipe for building JRuby's image that's mostly out of our hands

21:53 <cpuguy83> Yes.

21:53 <headius[m]> and we just need to update for version changes or other tweaks that make sense for JRuby

21:53 <enebo[m]> cpuguy83: that was my main worry about needing to be concerned about updates of the JVM piece

21:53 <enebo[m]> and we already have the recipe

21:53 <headius[m]> enebo: presumably by depending on something generic like openjdk8-jdk we get latest automatically then

21:53 <cpuguy83> So the images I have pinned to a somewhat generic version number so it should automatically pick up patch releases.

21:53 <headius[m]> right

21:54 <enebo[m]> so we just need some security aspect to push the spec and once per release we probably do it unless there is non-CVE base image updates maybe

21:54 <headius[m]> here's an example of what maybe we want to avoid: https://hub.docker.com/_/clojure

21:54 <enebo[m]> oh ok very cool

21:54 <headius[m]> I think we want to avoid anyway

21:56 <cpuguy83> There's also all these "adoptopenjdk" images... which I just don't understand the purpose of. https://hub.docker.com/_/adoptopenjdk?tab=tags

21:56 <cpuguy83> Like, the relationship between "openjdk" and "adoptopenjdk"

21:56 <headius[m]> it's just another build of OpenJDK

21:56 <cpuguy83> And then adoptopenjdk has openj9 and hotspot variants.

21:56 <headius[m]> so more independent of Oracle but there's still a company behind it (which I believe is either Microsoft or Amazon)

21:56 <headius[m]> yup

21:57 <headius[m]> we are figuring supported images will be only Java 8 and Java 11 (LTS release) on somebody's non-Oracle build (maybe we can find a Red Hat build)

21:57 <headius[m]> anything else people can assemble themselves

21:58 <cpuguy83> That makes sense, I did add 14 and 15, not sure if you want to keep those.

21:59 <enebo[m]> dinner prep

21:59 <headius[m]> probably not

21:59 <cpuguy83> The dockerfiles in the repo are the spec, and then there is https://github.com/docker-library/official-images/blob/master/library/jruby which tells the builders where to build from.

21:59 <enebo[m]> cpuguy83: thanks for this update on how this works. It was enlightening

21:59 <enebo[m]> cpuguy83: also not too lockstep with releases in that it may take time for it to arrive...so we will release and then at some nearisgh point we will get our image(s) out.

22:00 <cpuguy83> Also, changing the Dockerfiles does not affect the builds until you update that manifest.

22:05 <olleolleolle[m]> PS: This is all awesome, with improvement to official images being planned.

22:10 <headius[m]> yeah we'll get it done soon