 Can I log in as Jenkins? I'm not sure. I've definitely logged in as Jenkins. Anyway, we are live now. So yeah, welcome to the regular Q&A session for Google Summer Rockbook students in the Jenkins project. Apparently today is the last Q&A session for students in the Americas time zone. Let's agree that we need another one. So the application deadline is April 9. It's the next Tuesday. If somebody is interested, we can have another meeting next Monday, maybe just in the chat. So if you want to do so, we will just get it organized. It's generally on-demand meeting. So yeah, that's it from me. No specific introductions or status updates I needed for this meeting. So we can just proceed with questions. So yeah, if any of students has questions related to the JSOC process, et cetera, let's start from there. And if we have time, we will switch to the project specific questions. OK. So does anyone have questions about the process? And deadlines, any organizational questions, whatever. Can I just share my screen? I'm going to share my screen and ask just one question about the external workspace manager. It's definitely a project-related question. OK. If there is no process questions, let's just take a look at what we have in projects. OK. So I'm going to share project-specific questions. So here in this, I want to, there is a working flow I just come up with. So first, there is a disk pool ID. And then I'm going to detect this disk pool ID to decide whether it is EFS or not, whether it is predefined. And then when I find it is predefined, I need to check whether this instance is launched on EC2 because we're not in on EC2. You cannot use EFS, right? And then after I do all these checks, then I'm going to configure it to this slave on-demand. That is, when every step were executed, I'm going to monitor on it. Is this working flow, right? What? I think what you explained is what we actually expect. So what was the reason of my comment that, yeah, there are two ways of implementing the plan. One way is trying to pre-mount EFS. And yes, it was mentioned somewhere above. We should do that. But there is another way to spin this story where you do EFS mapping on-demand. So, for example, you execute pipeline and then you need more space. And at this point, you request a new workspace to be provisioned. And Jenkins does workspace provisioning and then performs mapping of the workspace. In such case, it would be closer to what we have in the plugin, for example, for common workspaces. Okay, I think that makes sense to me. And I think that is more doable and more clear because it was, so actually, now I just found this clear goal of this project. That's good. Thanks, Alex. I'm done with my share. Wait a minute. I can stop it. Okay. Okay, done. Thank you. Any other questions? You may also hit the participant limit. We need to rotate. Any other questions? There are so many people on the call, so there should be something. Yeah, hi. It would be nice if you adjust the sound settings because you're so silent now. Hello. Oh, yeah, now it's better. Yeah, so I had a couple of questions about my proposal. Okay, I'm sorry. I cannot share my screen right now. I'm not on my laptop. If you want. Hello. Yes. Yeah, so the first question was, you'd asked how would I start Jenkins from the jar file? Yeah, your proposal. Yeah, it's here. So you're talking about just search for the, yeah, here. So yeah, you see benchmarks jar file. So the tricky thing about Jenkins, that Jenkins itself is a runtime service. So you can adjust the classes and perform unit testing. It requires to have some context. For example, what we do in Jenkins test harness, we have a Jenkins tool, which actually spins up Jenkins. So you can actually use it as an application. Yeah, I had, I did suggest that. I just wanted to ask if that is good enough. Well, we look for the network key selector. Could you please repeat your question? Yeah. I'm sorry, I'm not able to get you. Yes. So there is enough. So that's why so difficult on the center. Okay. Just second. Okay. Now you're muted. So I can just answer, I believe. Okay. So yeah, my question was about the, it's another proposal. Yeah. So here you have benchmarks jar. So when you execute this benchmarks using Java, my micro benchmark framework, you, if you want to use Jenkins rule, firstly, you need to ensure that it's actually possible because Jenkins rule is designed specifically for JUnit. So this test rule is compatible with JUnit, but I'm not sure that the JMH can actually use JUnit rules as a part of the execution. So if you want to use Jenkins rule, it's something you need to check. Yeah, I've already tested that. It does not seem to work because possibly when we run a JMH test, it folks into new Java virtual machine. So we cannot run an instance which was originally used. Yeah, right. So you would even need to somehow work around it because the Jenkins rule, there is no magic inside. If you take a look at the code. Yeah. So I wanted to ask, would it be possible during the project to use something like the, I mean, like the method used by a Jenkins test on this? Well, if you get it working, that's perfectly fine. Okay. Yeah, so Jenkins rule, there is no magic there. You can probably copy this code and make it running as a part of JMH, which may be useful to have it as a separate library so that it can be reused by others. Okay. Because I had already tested that when the setup codes for, when the setup methods for JMH run, they run in the same process. So I think we'll be able to get it to work. Okay. So if you do that, it will be definitely useful and you can probably do it as a separate library so that it can be reused by other projects which need to perform as they stand. Okay. So I'll add that to my proposal. And another question is, you had asked about moving the documentation from the Viki to GitHub. Yeah. So is there any benefit of doing so? Well, firstly, the documentation is good because when the documentation is located in GitHub, then you can patch the documentation in terms of this code. So for example, you propose a tool request with new feature and write in this tool request, you write the documentation. So you merge the documentation and the feature at once. It's one of the benefits of such approach. Okay. Yeah, whether it's built in Viki for users, it's debatable. So if you just want to pay documentation, of course you can keep it on the Viki. But yeah, in the different plugins, you must use GitHub for the documentation. Okay. Yeah, so my advice is if you want to create a tank of new documentation, then yeah, better to use GitHub. You can write the documentation in a ski dock in Markdown. So it's something standard. Unfortunately, the Confluence format, well, it's used only in Confluence, I believe, but yeah, Markdown and a ski dock are much more preferable from projects standpoint, because at some point we can generate read the docs, for example, for this plugin if we need, or do something like that. Does it make sense? For example, we have to take the problem, not the live plugin, but this plugin has some documentation hosted in GitHub. So yeah, you can just... Well, generally you can just copy it and have everything here, or you can create multiple page documentation if needed. In this case, it's your decision. So if you want to keep documentation in Viki, just do that. If you want to migrate it, yeah, it's probably a good deliverable for the project, but yeah, obviously it's not according to set. Okay. Yeah. Okay. So let's move on to other question. If there is nothing left, but yeah, we can discuss more question and if you have any other projects, questions specifically, strategy we will return to them. Alex, Jack, do you have any questions? Oh, yeah. Do you hear me? Yes? Yes. Yeah, I ask in chat, but from your experience, what's the best lens for draft, for this kind of draft, for this Google draft? Because I could add additional steps and make appendix, but I don't know, should I... Or should it be like short and then it could be developed? Okay. So there are two approaches being used by students. One approach is to have a good project proposal. I mean, keep it short so that everybody understands what you want to do and then this type of top-level things like what would be deliverables, what would be the benefits for the community, what would be the timeline. So there are sections which I actually expected in Google Summer of Code documentation. One of the approaches which is widely used. Another approach is to actually use project proposals as a kind of mini design where you document everything you want to do at the level of digitalization you can achieve during the application phase. Both approaches are fine. So whatever is preferable for you, our expectation is that you have basic information. So it can be done in three or four pages, maybe even less, so you can start from there. If you want to add details like the mini design, like some research summaries, et cetera, yeah, if you perform such research, it makes sense to put it to the proposal because at some point it will be used to do the design for your project. What we do in Jenkins, we usually use community bonding in order to do a kind of mini design together with these mentors so that your proposal has some reality mapping and that you also create a list of tasks at least for the first coding phase. So when the coding period starts, you really can start coding. This is our objective for community bonding. So yeah, if you have time now, if you want to expand your proposal and to put some design ideas, et cetera, it definitely won't hurt. But yeah, if you just create a short proposal with three or four pages, with all summaries, et cetera, yeah, it's also key. Okay, I think I focus on short at first. Okay. Maybe align some aims, some developers because starting digging deeply. Yeah, I understand there is some, it could be additional, it could take additional time. Yeah, right. So yeah, summary deliverables is what we expect to be well written regarding design, regarding project ideas, if it's a brain dump, it's perfectly fine. But yeah, well, if you focus on the first part and then if you have time to do something for the second, this approach I would recommend as well. Okay. Do we have other topics? Just a small... Yeah. Do we need to provide any more contact information because the Google's, because Google's guidelines are just to provide the address and telephone numbers. Is it necessary to provide them? It's not necessary to provide them in Google Doc. So what we really need from you, we need email, but again, email, if you join the JSOC public mailing list, we need to get emails from them. So in your application, it's not necessary to specify any contacts, contacts maybe except GitHub ID or Jenkins user name if you have it. All other contacts are up to you. So if you are not comfortable about keeping these contacts, just remove them. If you want to provide them due to whatever reason, it's also perfectly fine. Okay. I would like to clarify, Oleg, in the official application on the Google website, you need to provide everything they ask, but as far as the student proposal is concerned, it's what Oleg said. Yeah, thanks for clarification. So be sure if you want to be using your email to send spam, you won't be using your phone number unless there is an emergency. So sometimes it happens, but even if there is an emergency, we can contact the JSOC support. Because, well, it may happen, for example, if Jenkins project consults your three to Jenkins world, and for example, if something goes wrong, then yeah, this phone number may be used, but in such case, mentors will just coordinate with you before your trip. So yeah, no need to put these contacts. Okay. I have a question. What will be the schedule for, like, these Hangouts meetings when community bonding phase, so it will be the same, like once a week, and then on the coding phase. Yeah, so what do we expect to happen during the community bonding phase? Firstly, all projects will have separate meetings with mentors and with students, and it will be the base meeting for you as a student. Then we will have weekly JSOC meeting, like we have now. It will be kind of office hours for Q&A, for status discussions, etc. So it will be an optional meeting. It won't be required to join it every time, similarly to these Q&A sessions. And in addition to that, there are also special interest group meetings. So you may have seen that some projects are linked to special interest groups or to sub-projects in Jenkins. Some of these entities also have meetings. So usually it's something like one is a meeting once per two weeks or so. And yeah, these meetings is something we would really recommend you to follow, because these meetings are just a pool of stakeholders for your project. When you need a review, when you need feedback, when you want to demo something. So going to these special interest group meetings is something we would advise. Again, the main meeting for projects is a kind of sync up with mentors. We usually recommend to have at least one meeting per week. In many cases it's two meetings per week. And yeah, it will be the main meeting for communications. Okay, thank you. Yeah, we think that you will be able to discuss the time with mentors, so that all of you will be able to find a comfortable time. You don't look very happy about it. No, I'm happy. It's okay, I just I had a huge problem with this Google handout. It's not supported in my laptop, so... Good news is that if you and mentors want to switch to another communication way it's also possible. Yeah, if you decide that you do a meeting for example in Zoom or whatever please feel free to do that. And actually, there is a wider discussion about Google Hangouts on the Jenkins organization level because we have a limit of 10 participants on the call, which is not enough for many meetings. And there are discussions about moving to other platform but we wait till at least delivery foundation is fully formed to have a discussion on the CDF level. So Jenkins project now transitions with one from one umbrella organization to another one and we are hopefully we will be able to use meeting platform of Linux foundation once everything is established. Actually, I just think that I have another question about evaluation process on the face. So it will be evaluated by mentors or there will be some additional people who will be involved at this face and we will have some wide meeting with several with presentation and with outcomes deliverables and so on. So what our plan says that after coding phase, there will be public presentation performed by all students. So this public presentation would be one of the ways to showcase your project and show the progress and this presentation will be a part of the evaluation. Generally, mentors are the ones who do the final decision but there are also stakeholders. For example, I mentioned special interest groups and these groups they meet regularly there will be some stakeholders and you can use them as additional source of feedback and of course, mentors also may use these groups as additional source of feedback if they want. Okay, thanks. Yeah, JSOG program itself heavily relies on mentors to make the decision as Oracle means we have a way to make the decision if something goes wrong but hopefully you won't need it. Okay, maybe next question. As I understand for there is a JIRA which I already signed up so the work will be like inside the JIRA on the project or it will be something different what will be the workflow for the proposed features and improvements. It depends on the project so Jenkins project has JIRA and JIRA is a default standard for most of the Jenkins components but some components opted out to get half issues for example if you work on a component which prefers half issues then it might be there but usually it's around JIRA but JIRA is used mostly for tracking feature requests etc so nobody is going to do micromanagement via JIRA so we don't do time tracking we don't do all other crappy things which you can probably do in JIRA so for us it's generally a back lock some kind of tracker okay so basically I could break down my timeline and put some tasks into JIRA and work sequentially on them so usually it's what we do using the community bonding so we have meetings with students so we make decisions what we really implement sometimes mentors want to change the project a bit to make it closer to the Jenkins community needs or to adjust the timeline to make it more feasible and then after such discussions yes a number of tickets is being created in Jenkins JIRA and then you can use it as a back lock no need to create tickets right now unless you really want to request a feature even if you don't want to work on this project but during community bonding it will happen anyway okay I also I also quickly look through the previous year project and yeah it's quite impressive and the question is this don't remember the name girl still continue to work on her proposed feature or is it like finished from 2018 from 2018 yeah there is presentation on Jenkins site to remember some if you clarify what is this project about maybe I will be able to read it because yeah right now I don't understand which project you mean I just forget okay no problem I will I will send you the link later in more details if you just think that this year all former successful JSOC students participate as mentors so for example we have Alex on the call he was a JSOC student in 2016 other students Xingyu and Wutuan they also participate as mentors this year so yeah so you roast I also have some question I like the program to my fellow students and yeah maybe it's particular question to you Oleg if there will be possibility like another student to take part on on that part which I am proposed to what do you think it will be okay I mean not the copy of my proposal but like additional features with login or something else is it yeah so what is the requirement of JSOC in that yeah there may be project applications and project which have some relation to each other but yeah the main requirement that each project can be separated separately and that each project can be successful separately even if something was wrong with its counterpart so if you create proposals which can coexist with each other yeah it's perfectly fun we will still need to find mentors on our site so we can actually guarantee anything that both projects will be selected but yeah even the project applications are independent enough it may be possible okay okay I will tell my fellow students about this okay Google Summer of Code is mostly about working in open source communities so any kind of collaboration they perfectly fine okay Martina I have to drop in few minutes but yeah do we have any questions left? I'm done for now thank you I'm really excited to ask questions in GitterChat if you have something specific to discuss because yeah my name is Liss and GitterChat are the main communication channels and this is just a way to have syn cups when needed since thank you so much okay so any other questions yep I can take over Oleg I'm not logged in as Jenkins so I will not be able to terminate the the broadcast but I can log in as Jenkins if that helps if we have no questions left maybe we could just close on the broadcast okay and take the remaining questions on in the chatroom it doesn't seem to have any questions okay I meant additional okay so if there is nothing clear to discuss thanks everybody and see you in the chat bye thanks bye