OpenJDK Governing Board Q&A
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Reinhold, Mark
Torre, Mario
Haley, Andrew
Saab, Georges
Lea, Doug
An open Q&A session with members of the OpenJDK Governing Board
 Okay, we're going to get started here in just a moment. We're doing our best to get Professor Douglas on Skype. One could probably question our choice of methods of getting him here, but in any event, we're going to see if that works. Other than that, I'm actually pleased to say that I think this is the most complete representation actually being physically here in the room that we've had in one of these sessions in Meet Space, as Andrew says. And so we'll just start out and quickly to make sure everyone is in the right place. This session is the Open JDK Governing Board Q&A. And so of course that means what we're going to do is let you guys ask us questions and then we're going to do our best to answer them. Right? That's how it works. Okay, and so before we do that, we'll just do some very brief introductions. So hi, I'm George. George Saab, I'm the chairperson of the Governing Board. I work at Oracle, so I'm also the vice president of the group that works on Java SE and ME and Card and associated stuff at Oracle. And I'll pass it to Andrew. I'm Andrew Haley. I work at Red Hat, but that's not how I got to be on the Governing Board. Hi. Hey, there's Doug. All right, Doug. How's it going? Oh, Doug's a soul. I'm going to turn it around. Yeah, yeah. Well, that's, yeah. Anyway, sorry. It's going to be like that, isn't it? I work for Red Hat, but I'm not on the Governing Board representing Red Hat. I'm there as, well, I'm there to represent you, really. I'm the at-large member. One of the at-large members, sorry, along with Doug. And I'm there because I want to represent you and the rest of the open JDK community. I don't represent Red Hat. Wow. Okay, go on. Go on, Doug. Talk to us. Hi, I'm Doug Lee. I'm surprised that I'm here on somebody's phone. I'm just like Andrew, just how he says. I'm here to represent you. I focus on academic research community, but hackers galore. My name's Mark. I work on Java. Oh, and I work for Oracle, so. My name's not Mark. Luckily, my name is John Dwiowicz. I work for IBM. I'm the vice chair of this fine open JDK governing board. And I'm a distinguished engineer, and I own all of the runtimes, including Java at IBM. And since we've been participating since 2011, somewhere around there, in open JDK, and as most of our Java runtimes actually built on all of the class libraries from open JDK, we're interested in continuing the innovation at the community with community members from this audience and others. Okay. Question? All right, so this is Q&A. So you did the question. Let me just say one thing. The very first time that we have all the governing board here, so from here, it's a great activity. It is beyond exciting. I'm so excited. I cannot believe it. Seriously. So thank you. Okay, and Mario, are you going to run around with this thing? We're going to make it. Sorry, take it back. All right, then people will have to yell. All right, Sonny. So I live in Hong Kong, so I haven't been here for a couple of years. The last time that it took company, which is in the 421st of April, how far have you got with that? So I know that it's going to be in Hong Kong in the last five years, but something has to be healed before they put it into that. Are we going anywhere with that? Yes. The question which I should repeat for posterity is what's happened about the open bug databases because we were talking about that last time, or a couple of years ago, I think it was. Yeah. We're doing okay kind of sort is my take on it. Open JDK members can create bugs, but nobody else can. Other people go through the Oracle gateway, which I think it's, am I right in thinking that's the general Java bug gateway rather than a specific open JDK bug gateway? That probably makes sense because end users don't necessarily know whether the bug that they've got is specifically open JDK or generally Java related. There is a problem in that until it's been triaged by staff at Oracle, it's quite hard for people to know what the status of the bug they've just created is. That's an ongoing problem. On the other hand, I think that the high quality bugs that we need in order to be able to act tend to be created by people who are open JDK members anyway, because they have the requisite knowledge to create all of the information that we need and to produce repeatable test cases and so on. I would argue that this still isn't an ideal situation, but I do understand the reasons for it. And the bar is actually not that high. You can change that if you get the author status and the current access. Yeah. And for posterity, Alexi Shiblov was saying the bar actually isn't that high to get to author status and then be able to get access to the database. I should point out that database is one. And I don't know exactly which year you were talking about, Sunny, but definitely in the beginning, we had a bunch of work to do to actually move from the legacy bug system that had been used by the team at Sun to the system which is being used today. And so it is the case that you can go and look yourself and see the bugs, see what's happening, see what responses people have made. And the only thing that is a bit of a challenge is if you want to go and report a bug directly and you haven't done a bunch of work and made contributions and gotten some level of status in the openJDK community, you need to do that through the sort of bug reporting system which is for Java users in general. And one of the reasons that we do have that at the moment is we get an immense amount of traffic there. There's really a lot. And I think it would not be ideal to have all of that traffic going directly into the openJDK bug database because there's just so much noise. That's like 95% of this Minecraft is graphic. That's true. Sorry, Alexi points out as I was just about to say, 95% of that are Minecraft video driver bug reports because when the VM crashes, it gives you the URL to that exact page. And millions of people do tofully file their Minecraft crashes. So there's a third channel that's worth mentioning. It's not a huge source, but it's not uncommon for developers who are familiar with openJDK as a community but not real active. They'll show up on a mailing list and say, hey, I've got this problem. And then somebody who does have access to the database says, oh yeah, that's a problem. And they basically create the bug for it. And that happens on an informal basis pretty frequently, I think. So if you're a member wannabe, find a friend to follow your bug. Could you say that again, Doug? I said if you would like to be a member, because you found a bug and you'd like to help fix it, the easiest path is find somebody else who's already a member. They can follow the bug and then you can collect brownie points for your membership. Yeah, and that's basically the algorithm for how to get involved is you find somebody to help you. That's true for many things. A different question in the back. In terms of non-X86 platforms, how are we doing? Spark is doing great. I'm trying to remember what he said. How are we doing in terms of, was it features and testing and quality for them? Yeah. Well, let's just go through the platforms. The non-X86, the JDK platforms, there's PowerPC, S390X, AR64 and Spark. Oh, no. Yes, I suppose so. Some people think it's cool. It's awesome. I agree. Yeah. The ARM32, Stoke64 port and the Spark port are also tested by Oracle, correct? The Spark port certainly is the ARM that combined one is too. Yeah. Yeah. Okay. Before we go now, I'm going to go over the... Yeah, that's right. That's right. Outside there, we have a number of partnerships in the community for things like the AR64 port. S390X, I don't know. I mean, you guys must be testing it, right? Along with the PowerPC. We're doing testing at Red Hat. I mean, one thing I can guarantee is that we're running the regression tests and we're running TCKs. So we do know that the other ports are compatible. What we don't have outside Oracle is the big bunch of heavy-weight applications, which I believe you're doing regular regression tests on. And it's something of a challenge for the community to pull together a whole bunch of big stuff that we can use for testing. Yes, that's still very much a work in progress. And in order to get everything up to the same sort of high level of quality, we're going to have to do more of that in the open. And I understand, I mean, that a lot of your tests that you do internally are proprietary anyway, so can't easily be opened up. So if you are not an ultra-game-taker, can you tell us if you cannot download an ultra-game-taker from security? Or you have to only accept the software, why not, but you can use it on the other side of the world. Okay, I'm not entirely sure. I understand what you're saying. Dukka, I think you're asking why don't we have HTTPS on at the very least for those of the people who can download the source code securely and have some assurance that there's no man in the middle giving them source code with bugs. This has been bugging me for quite a while. And it's something that I've been meaning to talk to the info team about, just haven't gotten around to it yet, we should do HTTPS preferably only on all of the open JDK infrastructure. We already do it on the bug database, I believe. But for all the rest, we should do the same thing. So we just need to work it out with the info team. And the way we need to do it to a few internal oracle approvals to get the certificates minted, but that's pretty straightforward. So, yeah. It's going pretty good. You got some complaints from the website. What do you got? Valker. During the last year, I was always complaining a lot, so this year I'm quite satisfied with... Whoa. Valker says he's quite satisfied. He's usually the guy who stands up and he's got a list. And he reads from the list. And as he goes down that list, we're all up, he's like, oh, oh, no, oh, no, oh. So I have maybe just one question this year. Recently we had a problem on the open JDK meetings. Somebody complained that the class library had a check-in with some code from Stack Overflow and a personal check. And I see in the end it turned out that the guy who was published is called a Stack Overflow, also an OIG employee. So I don't know if you can also get that type of problem. But my question is, are there any plans to do code scans or do you post some more checks on the code? Are there any plans to do code scans to catch code coming in that maybe shouldn't be coming in because its provenance is unknown or uncertain? Xerxes, do you have another question or did you want to comment on that? Another question, okay, you're just being very diligent, very good. You can rest your arm, we'll get you. Or maybe you've got a cramp in your stretching, that's fine too. Yeah, so the whole code provenance and all that. We did Oracle doesn't have any current plans to do any more. Do we as a governing board need to encourage someone to have plans for this? So far the honor system has worked pretty well, we did catch that one. We got a lot of lawyers, we scanned the shellac out of everything, so if you didn't think it's being scanned it is by us. However, however, you're welcome. But it would make good sense because the problems of the code, stuff happens, I think we should have some policy that would help us for sure. But it probably helps others because there's a lot of ways to get the wrong code in the wrong place and you guys are probably motivated the same. I'm surprised you're not scanning it or you're not admitting it, but here admit it. Well, I will say that there are a couple of things. I think in general code scans are done whenever Oracle does an acquisition, we look at all of the inbound IP and so that certainly was done. In fact, it was quite humorous when that was initially done on the JDK code because it immediately came up with lots and lots of warnings of things that were in some other bit of code. Because they were in the JDK. And so that's kind of interesting. No, no, no, no, I mean, because it was actually code that was in the JDK, which is a known bit of code that's out there that people shouldn't be copying and using, except this was the JDK. So that was kind of interesting. Thanks, BlackDoc. In any event, I think one thing that's worth keeping in mind, I think many of the folks who work in the open JDK community work at companies who have pretty strict rules. Around this kind of thing and are pretty used to that. I think that we do have some people who are sort of individuals who come in and work that may not be as used to that. It certainly is the case that the OCA has information about what's expected. So, you know, when you sign up and say, I'm going to, you know, I want to be a contributor to the open JDK. One of the things that you're saying is I'm going to be diligent myself about not taking code from somewhere and kind of contributing code that's not mine to do with. And so I think there already is that, you know, whether we, it makes sense to put something more in there. I think, you know, we've seen kind of one case where we had a question, you know, possibly surprisingly, I don't think we're aware of any others. And so, you know, my feeling would be, and, you know, we're kind of having a governing board discussion here in real time, is that, you know, unless we start to see that this is something that's clearly a problem, we don't necessarily need to worry about introducing additional friction. Yeah. Policy when it comes up. Whenever these things seem like they might require involvement by lawyers in creating more process documents, we cringe because that's open JDK governing board at its worst. We don't do anything because it takes so long to do anything. And the great example of that is, is, is something I thought I'd bring up since nobody, nobody asked yet is the, the brand new and thank God, it's finally proposed CSR project, which was just announced this week, and, and sure to go in effect. And this is a, finally, an open JDK process that corresponds to the, the evil secret society of, of, of CCC that people lived in fear from. And now we have, we will have a, a process for doing that without a huge process document. I am so, so proud of Mark of figuring out how to put this into effect without writing 100 pages about what it does to saying basically it does whatever the these sponsoring group would like it to do. I think it's us at our best and I want to publicly congratulate Mark for, for, for finally putting it. All right. Yeah, it's, it's a joke that I think we've made every year. And there's a danger of us getting to the end of the session without saying this. So I'll say it again, that in an ideal world, our job as a governing board is really not to do anything. We hope that the various sub communities within open JDK will be self organizing and they almost entirely are. Yes, there are infrastructure issues which tend to cross boundaries of teams and groups and organizations and all the rest of it. But we're, we're just there to make sure that the sub groups and all of the stakeholders have what they need in order to organize themselves. We don't want to run people's lives. Definitely. Yeah, okay. This is all to do with making binaries available. This has always been a very vexed question. I, I think there are lots of really, really good technical reasons why that is very, very difficult to do. And indeed the binary may not necessarily work on your system either. Can Oracle do it? Would Oracle want to do it? But publish, publish early access binaries on a more frequent basis. Under what license is always the question. I think Oracle, you know, we've had directions from the business side that shipping binaries under the GPL is not something that Oracle wants to see. I haven't, you know, I haven't asked that question again for a couple of years, but I got a pretty firm answer the first time I asked it. So I, you know, we've already been thinking that that for 10 it would make sense for Oracle to publish nightlies or hourlies, you know, or whatever's on a much more frequent automated basis. And of course, the Oracle JDK is not yet it's 99% open JDK right. It's not that different. But it's under the BCL, which some people won't be able to accept. Maybe maybe other organizations, you know, can step up and provide binaries under under other licensed terms to do. Do you want to reply to this? So, okay, so, so docus pointing out that the devian experimental and and and the bounties. What was the Ubuntu one? Okay, so the current current development line in Ubuntu will have open JDK binaries. Are those updated frequently? Mostly weekly. So that's another source. Are these Linux binary resource specific to Ubuntu? Yeah, okay. Yeah. So I think you just saw the reason you don't get a nightly binary for up to JDK because there are at least five builds that you're talking about. We have another one. Maybe I'll be the sixth and they're they are nightly available and depends on where. And so one to so everyone's building from source and there is no binary distribution from open JDK that that everyone can then unify on. So that is an opportunity. It's community would like to do by industry project. But I don't see why that wouldn't be a problem to just build it. But each of the five of the companies still do theirs. We all have separate builds. So I think that's where you're seeing the challenge. But so, so, yeah. And so everyone goes, Yeah, there's nightly's mine, mine, mine, and mine. Or you guys have the common one. Maybe Doug has a nightly. I don't know. Even Doug is crazy to have a nightly. So I don't know. But there is because that, you know, because you want to do the work last night. The answer is where what code did you get? What are the experimental guys have in there? It's kind of a mysterious thing. So maybe there could be a community effort around it. Not a bad story. But, you know, and we have, of course, a bigger problem. We have all sorts of additional code that's not part of the core yet. So hopefully we can fix that, too. So related to this question, you published some test results for the room? Maybe you just want to know the rest of the people. So related to this question, you published not only your Oracle binary builds, you also published test results, which is good. But you only published results like which from the regression tests. But you only published which results pass and which don't pass. And it would be good if you published the exact test details, the fires, the JTR fires, because a lot. Yes, I spoke with Roy about this. And I just wanted to bring this to your attention. A lot of tests, I mean, maybe they get not executed on your hardware on your platform. And the result, it's always OK. So if the test passes, it can mean it wasn't executed. It executed without errors or something in between. So a better publication would be good. There's more details. No, that's a good point. Publishing JTR files, technically, I don't think would be hard. We would probably run a follow some of the same issues we were having with the experimental submission forests in that we have to scrub test logs for internal host names and other stuff that we're just not allowed to reveal. But maybe maybe we can somehow combine those two efforts and if we have a general test, you know, test results scrubbing filter, we can use it in both systems. So yeah, it's a good idea. I think we're coming towards the end of our slot and FOSTA and staff are going to get rather impatient with us. So while this is all very interesting, I don't want to stop anybody talking. If there's one more really quick question and then I think we're done. Go on. With additional ports coming into Open JDK, AR64, and PPC, if there's a security issue to report, there's different owners. Who should I talk to? Okay, so that's actually one of the things that Mark discussed earlier today was the work that we've been doing on proposing an Open JDK vulnerability group. And I think we're just about there. There's one last detail that I'm trying to get pinned down and worked out. But the intent of that is basically that we have a place where it's very easy for anyone who finds something to come and report an issue so that all of the people who are involved and potentially can help in fixing that issue are able to find out about it and to sort of work with the rest of that group and actually being able to find a solution. And so I think that's kind of how we'll try to work that out. And we have a little bit of a sort of guidelines of what people might be people that would join that group and certainly having responsibility for a popular port or something like that would be one of those things. I think another is, you know, we've seen this happen fairly often where there's some possibly, you know, relatively obscure branch of the class libraries or something where a bug comes up and we really need to be able to find the world's expert on that. And, you know, that's not something you want to be doing when there's, you know, potentially a zero day vulnerability happening. Right. So a lot of this is trying to get that all mapped out and sort of work in advance of potential issues coming in so that you're able to act really quickly. And we can do that as a community in order to keep all of our users safe. And that's what I think I had in mind when I said we sometimes move way too slowly. If there needs to be lawyers and very careful wording, things just don't go fast and open JDK. Sorry. And I think Doug's right about that. You know, what I will say for this particular area is that one of the things that's contributed to it is, you know, the need to have lawyers from multiple parties kind of review it in the interest of trying to make it as good and tied in agreement as it can be. But also, I think because we actually do have some something that works today, it works non optimally and it's mostly not optimal for Oracle because at the end of the day, you know, we end up actually often having to have discussions with multiple parties, one on one, which really should be everyone getting together in a room and discussing. So it ends up being far more difficult and expensive for us than certainly I would like it to be. And so that's one of the reasons we've been pushing for this. But it's taken a while. And Doug's completely right on that one. I think in the meantime, you know, what we, what I can say is we have seen situations where people are unsure of where to report a bug. And then typically what happens is one of two things. If they're smart, hopefully they figure out where they got to build from. And they report it to whoever that is. If it's Oracle, if it's IBM, if it's Red Hat or Azure or whoever. And then I think, you know, those folks try to deal with those responsibly as they can. In some cases, we've sort of seen people scratching their heads and then, you know, posting, you know, details of a potential security vulnerability on mailing public mailing lists, which is not a good idea. Like, don't do that, please. You know, while people want to hear about the issues and try to fix them, you know, we don't want all of the details of those publicly known because the bad guys are looking too. So that's, so what I would say for right now is I think the best thing for people to do is try to report it to the people that they got a binary from. And I know, you know, if you're the business of doing that, you know, it's a good idea where you have downloads to also have information about how to report issues and how in particular to treat security issues. Another way of saying that is, even though we do not have good rules in place, we have some good people in place and things are not as bad as they could be. Yeah, things are not as bad as they could be. And I think that is a really excellent time to end this session. Thanks, Doug. All right, we'll talk to you soon. Take care. Cheers.
 Okay, we're going to get started here in just a moment.  We're doing our best to get Professor Douglas on Skype.  One could probably question our choice of methods of getting him here, but in any event,  we're going to see if that works.  Other than that, I'm actually pleased to say that I think this is the most complete representation  actually being physically here in the room that we've had in one of these sessions in  Meet Space, as Andrew says.  And so we'll just start out and quickly to make sure everyone is in the right place.  This session is the Open JDK Governing Board Q&A.  And so of course that means what we're going to do is let you guys ask us questions and  then we're going to do our best to answer them.  Right?  That's how it works.  Okay, and so before we do that, we'll just do some very brief introductions.  So hi, I'm George.  George Saab, I'm the chairperson of the Governing Board.  I work at Oracle, so I'm also the vice president of the group that works on Java SE and ME  and Card and associated stuff at Oracle.  And I'll pass it to Andrew.  I'm Andrew Haley.  I work at Red Hat, but that's not how I got to be on the Governing Board.  Hi.  Hey, there's Doug.  All right, Doug.  How's it going?  Oh, Doug's a soul.  I'm going to turn it around.  Yeah, yeah.  Well, that's, yeah.  Anyway, sorry.  It's going to be like that, isn't it?  I work for Red Hat, but I'm not on the Governing Board representing Red Hat.  I'm there as, well, I'm there to represent you, really.  I'm the at-large member.  One of the at-large members, sorry, along with Doug.  And I'm there because I want to represent you and the rest of the open JDK community.  I don't represent Red Hat.  Wow.  Okay, go on.  Go on, Doug.  Talk to us.  Hi, I'm Doug Lee.  I'm surprised that I'm here on somebody's phone.  I'm just like Andrew, just how he says.  I'm here to represent you.  I focus on academic research community, but hackers galore.  My name's Mark.  I work on Java.  Oh, and I work for Oracle, so.  My name's not Mark.  Luckily, my name is John Dwiowicz.  I work for IBM.  I'm the vice chair of this fine open JDK governing board.  And I'm a distinguished engineer, and I own all of the runtimes, including Java at IBM.  And since we've been participating since 2011, somewhere around there, in open JDK, and as  most of our Java runtimes actually built on all of the class libraries from open JDK,  we're interested in continuing the innovation at the community with community members from  this audience and others.  Okay.  Question?  All right, so this is Q&A.  So you did the question.  Let me just say one thing.  The very first time that we have all the governing board here, so from here, it's a great activity.  It is beyond exciting.  I'm so excited.  I cannot believe it.  Seriously.  So thank you.  Okay, and Mario, are you going to run around with this thing?  We're going to make it.  Sorry, take it back.  All right, then people will have to yell.  All right, Sonny.  So I live in Hong Kong, so I haven't been here for a couple of years.  The last time that it took company, which is in the 421st of April, how far have you got with that?  So I know that it's going to be in Hong Kong in the last five years, but something has to be healed  before they put it into that.  Are we going anywhere with that?  Yes.  The question which I should repeat for posterity is what's happened about the open bug databases  because we were talking about that last time, or a couple of years ago, I think it was.  Yeah.  We're doing okay kind of sort is my take on it.  Open JDK members can create bugs, but nobody else can.  Other people go through the Oracle gateway, which I think it's, am I right in thinking that's the general Java bug gateway  rather than a specific open JDK bug gateway?  That probably makes sense because end users don't necessarily know whether the bug that they've got is specifically open JDK or generally Java related.  There is a problem in that until it's been triaged by staff at Oracle, it's quite hard for people to know what the status of the bug they've just created is.  That's an ongoing problem.  On the other hand, I think that the high quality bugs that we need in order to be able to act tend to be created by people who are open JDK members anyway,  because they have the requisite knowledge to create all of the information that we need and to produce repeatable test cases and so on.  I would argue that this still isn't an ideal situation, but I do understand the reasons for it.  And the bar is actually not that high.  You can change that if you get the author status and the current access.  Yeah.  And for posterity, Alexi Shiblov was saying the bar actually isn't that high to get to author status and then be able to get access to the database.  I should point out that database is one.  And I don't know exactly which year you were talking about, Sunny, but definitely in the beginning, we had a bunch of work to do to actually move from the legacy bug system that had been used by the team at Sun to the system which is being used today.  And so it is the case that you can go and look yourself and see the bugs, see what's happening, see what responses people have made.  And the only thing that is a bit of a challenge is if you want to go and report a bug directly and you haven't done a bunch of work and made contributions and gotten some level of status in the openJDK community,  you need to do that through the sort of bug reporting system which is for Java users in general.  And one of the reasons that we do have that at the moment is we get an immense amount of traffic there.  There's really a lot.  And I think it would not be ideal to have all of that traffic going directly into the openJDK bug database because there's just so much noise.  That's like 95% of this Minecraft is graphic.  That's true.  Sorry, Alexi points out as I was just about to say, 95% of that are Minecraft video driver bug reports because when the VM crashes, it gives you the URL to that exact page.  And millions of people do tofully file their Minecraft crashes.  So there's a third channel that's worth mentioning. It's not a huge source, but it's not uncommon for developers who are familiar with openJDK as a community but not real active.  They'll show up on a mailing list and say, hey, I've got this problem.  And then somebody who does have access to the database says, oh yeah, that's a problem.  And they basically create the bug for it.  And that happens on an informal basis pretty frequently, I think.  So if you're a member wannabe, find a friend to follow your bug.  Could you say that again, Doug?  I said if you would like to be a member, because you found a bug and you'd like to help fix it, the easiest path is find somebody else who's already a member.  They can follow the bug and then you can collect brownie points for your membership.  Yeah, and that's basically the algorithm for how to get involved is you find somebody to help you.  That's true for many things.  A different question in the back.  In terms of non-X86 platforms, how are we doing?  Spark is doing great.  I'm trying to remember what he said. How are we doing in terms of, was it features and testing and quality for them?  Yeah.  Well, let's just go through the platforms.  The non-X86, the JDK platforms, there's PowerPC, S390X, AR64 and Spark.  Oh, no. Yes, I suppose so.  Some people think it's cool.  It's awesome.  I agree.  Yeah. The ARM32, Stoke64 port and the Spark port are also tested by Oracle, correct?  The Spark port certainly is the ARM that combined one is too.  Yeah.  Yeah.  Okay.  Before we go now, I'm going to go over the...  Yeah, that's right.  That's right.  Outside there, we have a number of partnerships in the community for things like the AR64 port.  S390X, I don't know.  I mean, you guys must be testing it, right?  Along with the PowerPC.  We're doing testing at Red Hat.  I mean, one thing I can guarantee is that we're running the regression tests and we're running TCKs.  So we do know that the other ports are compatible.  What we don't have outside Oracle is the big bunch of heavy-weight applications, which I believe you're doing regular regression tests on.  And it's something of a challenge for the community to pull together a whole bunch of big stuff that we can use for testing.  Yes, that's still very much a work in progress.  And in order to get everything up to the same sort of high level of quality, we're going to have to do more of that in the open.  And I understand, I mean, that a lot of your tests that you do internally are proprietary anyway, so can't easily be opened up.  So if you are not an ultra-game-taker, can you tell us if you cannot download an ultra-game-taker from security?  Or you have to only accept the software, why not, but you can use it on the other side of the world.  Okay, I'm not entirely sure.  I understand what you're saying.  Dukka, I think you're asking why don't we have HTTPS on at the very least for those of the people who can download the source code securely  and have some assurance that there's no man in the middle giving them source code with bugs.  This has been bugging me for quite a while.  And it's something that I've been meaning to talk to the info team about, just haven't gotten around to it yet, we should do HTTPS  preferably only on all of the open JDK infrastructure.  We already do it on the bug database, I believe.  But for all the rest, we should do the same thing.  So we just need to work it out with the info team.  And the way we need to do it to a few internal oracle approvals to get the certificates minted, but that's pretty straightforward.  So, yeah.  It's going pretty good.  You got some complaints from the website.  What do you got?  Valker.  During the last year, I was always complaining a lot, so this year I'm quite satisfied with...  Whoa.  Valker says he's quite satisfied.  He's usually the guy who stands up and he's got a list.  And he reads from the list.  And as he goes down that list, we're all up, he's like, oh, oh, no, oh, no, oh.  So I have maybe just one question this year.  Recently we had a problem on the open JDK meetings.  Somebody complained that the class library had a check-in with some code from Stack Overflow and a personal check.  And I see in the end it turned out that the guy who was published is called a Stack Overflow, also an OIG employee.  So I don't know if you can also get that type of problem.  But my question is, are there any plans to do code scans or do you post some more checks on the code?  Are there any plans to do code scans to catch code coming in that maybe shouldn't be coming in because its provenance is unknown or uncertain?  Xerxes, do you have another question or did you want to comment on that?  Another question, okay, you're just being very diligent, very good.  You can rest your arm, we'll get you.  Or maybe you've got a cramp in your stretching, that's fine too.  Yeah, so the whole code provenance and all that.  We did Oracle doesn't have any current plans to do any more.  Do we as a governing board need to encourage someone to have plans for this?  So far the honor system has worked pretty well, we did catch that one.  We got a lot of lawyers, we scanned the shellac out of everything, so if you didn't think it's being scanned it is by us.  However, however, you're welcome.  But it would make good sense because the problems of the code, stuff happens, I think we should have some policy that would help us for sure.  But it probably helps others because there's a lot of ways to get the wrong code in the wrong place and you guys are probably motivated the same.  I'm surprised you're not scanning it or you're not admitting it, but here admit it.  Well, I will say that there are a couple of things.  I think in general code scans are done whenever Oracle does an acquisition, we look at all of the inbound IP and so that certainly was done.  In fact, it was quite humorous when that was initially done on the JDK code because it immediately came up with lots and lots of warnings of things that were in some other bit of code.  Because they were in the JDK.  And so that's kind of interesting.  No, no, no, no, I mean, because it was actually code that was in the JDK, which is a known bit of code that's out there that people shouldn't be copying and using, except this was the JDK.  So that was kind of interesting.  Thanks, BlackDoc.  In any event, I think one thing that's worth keeping in mind, I think many of the folks who work in the open JDK community work at companies who have pretty strict rules.  Around this kind of thing and are pretty used to that.  I think that we do have some people who are sort of individuals who come in and work that may not be as used to that.  It certainly is the case that the OCA has information about what's expected.  So, you know, when you sign up and say, I'm going to, you know, I want to be a contributor to the open JDK.  One of the things that you're saying is I'm going to be diligent myself about not taking code from somewhere and kind of contributing code that's not mine to do with.  And so I think there already is that, you know, whether we, it makes sense to put something more in there.  I think, you know, we've seen kind of one case where we had a question, you know, possibly surprisingly, I don't think we're aware of any others.  And so, you know, my feeling would be, and, you know, we're kind of having a governing board discussion here in real time, is that, you know, unless we start to see that this is something that's clearly a problem,  we don't necessarily need to worry about introducing additional friction.  Yeah.  Policy when it comes up.  Whenever these things seem like they might require involvement by lawyers in creating more process documents, we cringe because that's open JDK governing board at its worst.  We don't do anything because it takes so long to do anything.  And the great example of that is, is, is something I thought I'd bring up since nobody, nobody asked yet is the, the brand new and thank God, it's finally proposed CSR project, which was just announced this week,  and, and sure to go in effect. And this is a, finally, an open JDK process that corresponds to the, the evil secret society of, of, of CCC that people lived in fear from.  And now we have, we will have a, a process for doing that without a huge process document. I am so, so proud of Mark of figuring out how to put this into effect without writing 100 pages about what it does to saying basically it does whatever the  these sponsoring group would like it to do. I think it's us at our best and I want to publicly congratulate Mark for, for, for finally putting it.  All right.  Yeah, it's, it's a joke that I think we've made every year. And there's a danger of us getting to the end of the session without saying this. So I'll say it again, that in an ideal world, our job as a governing board is really not to do anything.  We hope that the various sub communities within open JDK will be self organizing and they almost entirely are. Yes, there are infrastructure issues which tend to cross boundaries of teams and groups and organizations and all the rest of it.  But we're, we're just there to make sure that the sub groups and all of the stakeholders have what they need in order to organize themselves. We don't want to run people's lives.  Definitely.  Yeah, okay. This is all to do with making binaries available. This has always been a very vexed question.  I, I think there are lots of really, really good technical reasons why that is very, very difficult to do. And indeed the binary may not necessarily work on your system either.  Can Oracle do it? Would Oracle want to do it? But publish, publish early access binaries on a more frequent basis. Under what license is always the question.  I think Oracle, you know, we've had directions from the business side that shipping binaries under the GPL is not something that Oracle wants to see.  I haven't, you know, I haven't asked that question again for a couple of years, but I got a pretty firm answer the first time I asked it. So I, you know, we've already been thinking that that for 10 it would make sense for Oracle to publish nightlies or hourlies,  you know, or whatever's on a much more frequent automated basis. And of course, the Oracle JDK is not yet it's 99% open JDK right. It's not that different.  But it's under the BCL, which some people won't be able to accept. Maybe maybe other organizations, you know, can step up and provide binaries under under other licensed terms to do.  Do you want to reply to this?  So, okay, so, so docus pointing out that the devian experimental and and and the bounties.  What was the Ubuntu one?  Okay, so the current current development line in Ubuntu will have open JDK binaries. Are those updated frequently?  Mostly weekly. So that's another source.  Are these Linux binary resource specific to Ubuntu?  Yeah, okay.  Yeah. So I think you just saw the reason you don't get a nightly binary for up to JDK because there are at least five builds that you're talking about.  We have another one. Maybe I'll be the sixth and they're they are nightly available and depends on where. And so one to so everyone's building from source and there is no binary distribution from open JDK that that everyone can then  unify on. So that is an opportunity. It's community would like to do by industry project. But I don't see why that wouldn't be a problem to just build it.  But each of the five of the companies still do theirs. We all have separate builds. So I think that's where you're seeing the challenge.  But so, so, yeah. And so everyone goes, Yeah, there's nightly's mine, mine, mine, and mine. Or you guys have the common one.  Maybe Doug has a nightly. I don't know. Even Doug is crazy to have a nightly. So I don't know. But there is because that, you know, because you want to do the work last night.  The answer is where what code did you get? What are the experimental guys have in there? It's kind of a mysterious thing. So maybe there could be a community effort around it.  Not a bad story. But, you know, and we have, of course, a bigger problem. We have all sorts of additional code that's not part of the core yet.  So hopefully we can fix that, too.  So related to this question, you published some test results for the room?  Maybe you just want to know the rest of the people.  So related to this question, you published not only your Oracle binary builds, you also published test results, which is good.  But you only published results like which from the regression tests. But you only published which results pass and which don't pass.  And it would be good if you published the exact test details, the fires, the JTR fires, because a lot. Yes, I spoke with Roy about this.  And I just wanted to bring this to your attention. A lot of tests, I mean, maybe they get not executed on your hardware on your platform.  And the result, it's always OK. So if the test passes, it can mean it wasn't executed. It executed without errors or something in between.  So a better publication would be good. There's more details.  No, that's a good point. Publishing JTR files, technically, I don't think would be hard.  We would probably run a follow some of the same issues we were having with the experimental submission forests in that we have to scrub test logs for internal host names and other stuff that we're just not allowed to reveal.  But maybe maybe we can somehow combine those two efforts and if we have a general test, you know, test results scrubbing filter, we can use it in both systems.  So yeah, it's a good idea.  I think we're coming towards the end of our slot and FOSTA and staff are going to get rather impatient with us.  So while this is all very interesting, I don't want to stop anybody talking.  If there's one more really quick question and then I think we're done.  Go on.  With additional ports coming into Open JDK, AR64, and PPC, if there's a security issue to report, there's different owners. Who should I talk to?  Okay, so that's actually one of the things that Mark discussed earlier today was the work that we've been doing on proposing an Open JDK vulnerability group.  And I think we're just about there. There's one last detail that I'm trying to get pinned down and worked out.  But the intent of that is basically that we have a place where it's very easy for anyone who finds something to come and report an issue so that all of the people who are involved and potentially can help in fixing that issue are able to find out about it and to sort of work with the rest of that group and actually being able to find a solution.  And so I think that's kind of how we'll try to work that out. And we have a little bit of a sort of guidelines of what people might be people that would join that group and certainly having responsibility for a popular port or something like that would be one of those things.  I think another is, you know, we've seen this happen fairly often where there's some possibly, you know, relatively obscure branch of the class libraries or something where a bug comes up and we really need to be able to find the world's expert on that.  And, you know, that's not something you want to be doing when there's, you know, potentially a zero day vulnerability happening. Right. So a lot of this is trying to get that all mapped out and sort of work in advance of potential issues coming in so that you're able to act really quickly.  And we can do that as a community in order to keep all of our users safe.  And that's what I think I had in mind when I said we sometimes move way too slowly.  If there needs to be lawyers and very careful wording, things just don't go fast and open JDK. Sorry.  And I think Doug's right about that. You know, what I will say for this particular area is that one of the things that's contributed to it is, you know, the need to have lawyers from multiple parties kind of review it in the interest of trying to make it as good and tied in agreement as it can be.  But also, I think because we actually do have some something that works today, it works non optimally and it's mostly not optimal for Oracle because at the end of the day, you know, we end up actually often having to have discussions with multiple parties, one on one, which really should be everyone getting together in a room and discussing.  So it ends up being far more difficult and expensive for us than certainly I would like it to be. And so that's one of the reasons we've been pushing for this. But it's taken a while.  And Doug's completely right on that one. I think in the meantime, you know, what we, what I can say is we have seen situations where people are unsure of where to report a bug.  And then typically what happens is one of two things. If they're smart, hopefully they figure out where they got to build from. And they report it to whoever that is.  If it's Oracle, if it's IBM, if it's Red Hat or Azure or whoever. And then I think, you know, those folks try to deal with those responsibly as they can.  In some cases, we've sort of seen people scratching their heads and then, you know, posting, you know, details of a potential security vulnerability on mailing public mailing lists, which is not a good idea.  Like, don't do that, please. You know, while people want to hear about the issues and try to fix them, you know, we don't want all of the details of those publicly known because the bad guys are looking too.  So that's, so what I would say for right now is I think the best thing for people to do is try to report it to the people that they got a binary from.  And I know, you know, if you're the business of doing that, you know, it's a good idea where you have downloads to also have information about how to report issues and how in particular to treat security issues.  Another way of saying that is, even though we do not have good rules in place, we have some good people in place and things are not as bad as they could be.  Yeah, things are not as bad as they could be. And I think that is a really excellent time to end this session.  Thanks, Doug.  All right, we'll talk to you soon. Take care.  Cheers.
OpenJDK_Governing_Board_Q_A_0_131.png OpenJDK_Governing_Board_Q_A_132_647.png OpenJDK_Governing_Board_Q_A_648_767.png OpenJDK_Governing_Board_Q_A_768_1151.png OpenJDK_Governing_Board_Q_A_1152_1415.png OpenJDK_Governing_Board_Q_A_1416_3071.png OpenJDK_Governing_Board_Q_A_3072_3335.png OpenJDK_Governing_Board_Q_A_3336_3839.png OpenJDK_Governing_Board_Q_A_3840_3971.png OpenJDK_Governing_Board_Q_A_3972_6407.png OpenJDK_Governing_Board_Q_A_6408_6659.png OpenJDK_Governing_Board_Q_A_6660_9215.png OpenJDK_Governing_Board_Q_A_9216_9983.png OpenJDK_Governing_Board_Q_A_9984_10367.png OpenJDK_Governing_Board_Q_A_10368_11267.png OpenJDK_Governing_Board_Q_A_11268_12035.png OpenJDK_Governing_Board_Q_A_12036_12671.png OpenJDK_Governing_Board_Q_A_12672_14471.png OpenJDK_Governing_Board_Q_A_14472_16895.png OpenJDK_Governing_Board_Q_A_16896_17279.png OpenJDK_Governing_Board_Q_A_17280_19079.png OpenJDK_Governing_Board_Q_A_19080_20351.png OpenJDK_Governing_Board_Q_A_20352_20483.png OpenJDK_Governing_Board_Q_A_20484_24707.png OpenJDK_Governing_Board_Q_A_24708_25475.png OpenJDK_Governing_Board_Q_A_25476_26903.png OpenJDK_Governing_Board_Q_A_26904_27527.png OpenJDK_Governing_Board_Q_A_27528_29063.png OpenJDK_Governing_Board_Q_A_29064_29831.png OpenJDK_Governing_Board_Q_A_29832_32255.png OpenJDK_Governing_Board_Q_A_32256_32639.png OpenJDK_Governing_Board_Q_A_32640_32711.png OpenJDK_Governing_Board_Q_A_32712_32795.png OpenJDK_Governing_Board_Q_A_32796_38579.png OpenJDK_Governing_Board_Q_A_38580_49115.png OpenJDK_Governing_Board_Q_A_49116_49283.png OpenJDK_Governing_Board_Q_A_49284_49331.png OpenJDK_Governing_Board_Q_A_49332_49448.png