 All right. Welcome to the last session of the day. And for this talk, we will be listening to the Debian Outreach team that you struck, Outreachy Projects. There's quite a lot to go through, and we look forward to listening to them. That's all, yeah. Good afternoon, everyone. Welcome to Debian Outreach session. I am Pranav. And in this session, I would be talking very briefly about what is Google Summer of Code and Outreachy, and then mentors and students will present their projects. So whosoever hasn't heard about Summer of Code, please, it doesn't mean that you need to sit outside in summers and do coding. So what exactly is Summer of Code? It's a three-month remote program whose aim is to bring more and more students into open-source development. In this program, every student is paired with a dedicated organization and a mentor. So it has advantages for both the organization as well as the students. Organizations get to work with new talent, and whereas students get to work on real-life projects. Now, about the statistics, GSOC has been running from last 14 years. More than 14,000 students from 109 countries have contributed more than 35 million lines of code. There are plethora of organizations for students to choose from. In total, there are 651 organizations working with GSOC right now. There's a stipend between 24-update USD to 6,600 USD, depending from the place where you belong to. Like for Brazil, it's 3,600 USD. You need to be at least 18 years old, and you need to be a part-time or a full-time student to be eligible for GSOC. I have seen students from a lot of backgrounds. You can be doing a musical degree or a philosophy degree. You can be an undergrad, post-grad, or a PhD student. Now, going to Outreachy. Outreachy is very similar to Google Summer of Code. It's again a three-month program, but it runs twice a year. It is open for both students and non-students, and its main aim is to increase diversity in tech. It pays 5,500 stipend and a $500 travel grant to present your projects at the conferences. Also, I want to take this opportunity to thank the past outreach delegation who have been working since many years. We had Sylvester, Nicholas, and Tom. Now, the current outreach team has Molly, Gemini, Pranav, and Alexander who is helping us with the GSOC administration. Now, we will start with the student and mentors' presentation. We will take all the questions in the end, and you can also post on Debian Outreach IRC channel. So first, we have Arthur and Lucas presenting Cloud Image Finder Project. Hello, hello. Hello, everyone. So what we present about my project, the project that I've been working on, and the project is called Cloud Image Finder for Debian. And this project, you can see it on Debian Cloud Team now, and I will talk more about me first. I'm a software engineering student at University of Brasilia now. I'm a researcher at Lapis. It's a lab on the university, and also doing GSOC for Debian. Okay, now the app. This app is made in Flask, a Python framework, and it aims to make easy to find Debian Cloud Images. So I will make history now because the Cloud Team now is building a lot of images for Debian and all the providers. And these images, there's a bunch of metadata that we can track now. So we need to track this metadata, and we need to store them in a database. So that's the project it's doing now. So we will have an API, and this API you can create new providers for if we don't have yet digital versions, so this API will do that, so yeah. And also we can put images and all this data. We have a RSS feed, and this feed, we can check new images, and we can link everything that is in the cloud now. And the last one is the filter. The filter, you can search all the images and you can apply filters to have a specific images that you want. So here's a quick demo that I have. So we have the first page, you have the providers, and when you select the provider, you got a new page, and this page is a specific detail about the provider, and also you have a description. In the right, you have a card that helps you, helps the user so you can send messages to RSC or the Debian mail list. In the bottom, you have all the images, and these images in the bottom have the filters to release architecture and version, so you can do everything you want here. The second demo I have, you can do a general search, so you can do in the top, you can type everything you need, and you redirect you to another page, and this page, you can do the same, but for all the images that we have, and also you can mark which provider you want to have that image. Also, if you click on one of these images, you will have a page for more details about it. The next and the last one I have is the RSS feed, so if you click in the top left, top right of the page, you have, that's the proof that we have the RSS feed. So the next steps we have been working on, we will try to integrate with the Debian infrastructure now, so we need to package everything, and the next thing we're trying to do is to create a API key so we cannot have a span inside it. So yeah, that's it, thank you. Thanks, Arthur. Next we have Utkarsh presenting his Lumio project. Hello, everyone. My project is to package Lumio for Debian repositories, and my mentors are Abhijit and Raju. So who am I? I am a 19 year old Debian maintainer, second year undergrad student, a GCI mentor, PSF member and a contributor, and I'm doing GSOC with Debian, and I go by Utkarsh2102 across the web. What is Lumio? Lumio is a decision making software. It's, it is basically, it basically helps in making collaborative decisions, and it is of course a free software, and yeah, more information can be found on Lumio.org, and basically this is a typical way to use Lumio. You first create a group, then a group creates a thread. Thread turns into a proposal, and with the help of the proposal, the way it is handled, you get an outcome. How does it look? Well, it looks something like this. Someone opens a proposal, we could have, you know, we could vote, and we could write our comments down below, and yeah, so that is how it looks. What needs to be done? So, Lumio is written in Ruby Coffee Script, View and JavaScript. Also, it has 80 direct Ruby dependencies, 73 node dependencies, and a couple of fonts that are needed to be packaged. Apart from that, well, dependencies do have sub-dependencies. So in total, we have 134 Ruby gems and 127 node modules that are needed by Lumio. Thankfully, some are packaged, and, but for the others, we need to upgrade or downgrade the version as required by Lumio. Oh, the master plan. Well, that is the master plan to package, I mean, that was the plan to package Ruby and node dependencies in the first phase. The second phase was to check to package Lumio and write scripts, maintainer scripts, add user script, et cetera, engineXconfiguration, et cetera, and the third phase was to make Lumio installable on Debian Machine and fix its auto-piggy test. Well, what happens in case of test failures? We play the blame game. That is Raju and that is Abhijeet. These are my mentors, and we kind of blame each other for having all the test failures. Total work done till now. Almost all Ruby gems are fixed and uploaded, that are, I think, 50 plus. Test failures for gems are fixed, except two, to remain. Lumio installers is almost done, and yeah, that is the amount of packages that I've done till now. 52 plus 79. What all is left? Well, fixing and setting up Lumio installer, fix and upload all the node modules, and then finally, fix and upload Lumio. Of course, it is not possible to complete the whole project by the end of GSOC, but I'll continue to work on it after GSOC with my DM and DD hat on. So yeah, these are my other Debian activities during the GSOC period, other than GSOC, helping in maintenance of packages like disparagate lab rails, et cetera, uploading and reviewing sponsor and sponsoring other packages, helping in Node.js transition, solving CB and RC bugs, helping Ruby team, Node team, Golang team, and Poel team, and I think a couple more. Yeah. Part of Ruby, part of Versaity team, and content team for Defconn 19, and of course the Poel tree, Poel prints. So that is it, thank you. If you have questions, you can ask them after the presentation. Thanks, Otkarsh. Next we have Andreas, who is a long time outreachee mentor, and he will be sharing his experience. Hello, my name is Andreas Tiller. I just learned I should introduce myself in Brazil if I'm asked where I'm from, I should say seven to one. Maybe you get the joke, I liked it a lot. So I'm a Debian developer since 1998, and since 2011, I'm mentoring students in Kleesog, and later in outreachee. The first student I was mentoring was doing the so-called team matrix project. Team matrix is something where I try to count the contributions of contributors of some teams in different measures like mailing lists, and uploads, and commits. And the students did quite a good work, which I'm basing until today, several graphs on in my other talks, and this was a really nice project. Two other G-Sog projects were about blends. Maybe you have seen the Freedom Box talk before lunch. It is kind of sub-projects inside Debian for certain topics, and we did some framework around. One is other web pages, which needed some overall, which was done in one project, and one are meta-packages, which needs some overall, that was done in the other project. The lessons of the students were quite successful. I was happy, but the lesson I have learned was if the project is something that takes longer than the period of the outreachee student is working. You have trouble to get this into production because the students get on with their studies, and then the work is on the shoulders of the maintainers, or the mentor on this, that was me, and I did not really finish what was a very promising start. So this was not really in production, gave some good influences, was positive, and I would not say it was worthless, but the final outcome was not so good. As in the next processes, I did where I have very small tasks for the students, which is writing and continuous integration tests for several of our packages. I'm running the Debian Meet project, we have five or not, maybe more packages in the field of biology. I'm not a biologist, and all these students were bioinformaticians, so they had the knowledge what the programs should do, had the data that were needed to feed into the programs and the right expectation what the programs should do. And so I sorted the list of our packages according to the popularity, using popularity contest, and they started with the first one which had no continuous integration test, and wrote the test, and then we working down the list. And I'm doing this since five years now. I had two Google Summer of Code students. One of them was not so happy, but the outreach students were all very good. They are, by chance they were from all Russian, from St. Petersburg, and they recommended each other. And so this was kind of continuous flow of people from the same university, which was very good for me, because there was kind of a handover of these projects. And one of the students was two years ago in Montreal presenting the work, which was very nice. I always be happy if the students are presenting their work. This was also the case for the team matrix project in Banyaluka, and last year was, Yubov was not able to come to the Debcons, but she joined our Debian Midsprint. Debian Midsprint is a very small meeting of the Debian Midsprint team, about 20 people. We were in Lithuania, and in Lithuania I teach her how to build Debian packages, and since then she is packaging like crazy, and is contributing a lot to our project, which is very good. I'm really happy about this. So we have some students with successful work regarding getting something into production. We have some students who did good work, but it was only parts of it, finally useful, and which is the most important thing, which is the goal of this outreach project. We have a student who remains in our project and is constantly contributing, this is the best case. Yeah, this is basically what I would like to say now, and if you have questions you can do this later. Thank you, Andreas. Next we have a project from Kandy, but unfortunately she couldn't travel, but she has sent a very nice video about the project, and we also have a mentor, Antonio here. So I'll just play that video. I'm going to talk about my Debian CI project with Outreach, and I'm the 2019 May to August round intern, and I'm Kandy and I'm my IRC, K, A, and Z, I. Prior to my internship, I'm a front-end developer, and the things I work with is HTML, CSS, JavaScript, and with frameworks with React, so Ruby is very new to me. Through the process of making small contributions, it felt good, and Tesoro and Elbrus are very nice people, and although not a lot of people are working on Debian CI, but it feels very active, and I prefer small communities myself, so I think it's a perfect fit for me. The goal of Debian CI is to make sure that the packages will pass their tests before a major Debian release, and for individual developers, it's a place where you can request a test for your packages. My internship project is to improve the user experience of the ci.debian.net website, which I work on a UI to let users submit their tests and see the tests that they submitted. Currently for developers that want to request their own tests, they have to go to the API section and then read through this, and then they will find here a place that how they should formulate their JSON request, and then they should send their request by curl, postman, et cetera, which is not so user-friendly, and plus when they finish their tests, for example, if I ran a test for Vagrant, I have to click through here, and then click into Vagrant, and then check which architecture and suite I'm in, and then click into it to see my tests results. My project is to work on a self-service section which can let users send their requests on the website, and then they can also see their results, like a whole list, and without doing all that clicking. So the current progress is that we can go into the self-service section, and then we have a request test section where we can choose from upload a JSON file or just submit a test request form. And the other part is to show history section which will show all of what has been ran by this user, and you can use filters such as architecture. See, we have AMD64 and MRM here, and then we just want AMD64. So we can apply filters to it. So the challenges I had were setting up the environment which was really frustrating, and I decided to also write a Vagrant file so that when other newcomers are coming into the DevCI project, they don't have to set up everything from scratch. And another challenge is not familiar with Ruby, but that's also why I chose this project. The biggest problem was that my merge request over time got too big and became too hard to merge. Another is the time difference with my mentors. Me, Elbers, and Tessera, we live in three completely different time zones. So our meetings had to take place at only a certain time because that's the plan that was perfect for all of us. And it's my first time doing remote work. So I had a lot of guilt, like I was watching Netflix when I was coding or when I was waiting for Vagrant to build, I went and cooked something to eat, and that's really weird. You don't get that in an everyday office environment. I mentioned that I had really, really large merge requests. So we had a pair programming session where Tessera sat down and we took a few hours and he demonstrated how to make my merge request smaller and more easier to review. And also because I'm not a user of DevCI, so I had to know more about DevCI from my mentors so that I can deliver features that might be more relevant to the actual users that are using it. As for code reviews, they were also a big help because that's our main means of communication because we live in very different parts of the world so we can't always be awake. And they were always very, very supportive. Through this process, where the biggest thing I've learned is that some people will not enable their JavaScript when they're using the website because for sites such as Facebook or Twitter, they always give you this big fat warning. If you don't turn on your JavaScript, you will not be able to use the site properly. And this also made me realize that sometimes the users are doing things that you're not expecting them to do, which means that the code I wrote for DevCI will always have support for non-Jobscript users. That's it for my sharing and hope you all have a great time at DevCon. This is where to find DevCI. And the last we have Kim presenting the Reels Package Project. First of all, thank you for Outreach Team for giving me an opportunity to talk in this session. I am a Ruby JISOC student. I attended the last DevCon F and learned Devian packaging there. And now I am a Devian maintainer. My JISOC project is bumping up the Reels package version from five to six in Devian. My mentors are Shruti, Shruti is there. She's a Devian developer and Tessie. Tessie is an experienced Ruby developer. Reels is multiple binary packages. It has 12 binary packages. Until five, it has 10 packages. And from six, I will introduce two more packages into Devian. Its meta package is Ruby Reels and its source package is Reels. It has a lot of dependencies, 81 dependencies and 184 reverse dependencies. Ruby on Rails in Devian is 2.5.2.2.1. And Ruby on Rails 6 was planned for releasing on April 30th. However, not yet released. So I am working with Ruby on Rails release candidate, RC1. I broke into three phases my project. First is transitioning Ruby libraries. First is transitioning Ruby on Rails dependencies. Second one is upgrading the Rails itself. And the last one is upgrading and patching the Ruby on Rails reverse dependencies. I, first I did was upgrading the dependencies. I estimated which one is broken and which one is working well. So 11 Ruby libraries was broken, not working with Ruby on Rails. So I patched and upgraded 11 Ruby libraries. Five packages was already in Devian and I introduced six more packages into Devian. And then I upgraded the Ruby on Rails. I tried, there are some test failures in Ruby on Rails itself. Even in currently packaged in Devian. Well, I tried to fix all of test failures but right now a lot of time will be consumed. So I gave up and my mentor suggested me disabling the test and upload to experimental first. So I will do right now and my mentor is reviewing my package right now. What should I do from now is upgrading the reverse dependencies. There are 180 for reverse dependencies are currently in Devian. 12 of them are Rails apps and one, the rest of them are Rails libraries. I am currently estimating the broken reverse dependencies, which one is broken and which one is working well. This is a QA page of mine. I uploaded five new packages and five, I patched five packages. This is all URLs, how to track my works. The first one is JISO project page and second one is Rails project in Rails package in Salsa. And the third one is my project tracker in Devian Wiki. Thank you. Thanks, Kim. So that's it what we have. If you have any question for the students or mentors or for the outreach team, we are happy to answer. Thank you. So Andrea said asking how many of you are the mentors or the students for these programs here? Can we just have a show of hands please? I think we don't have any questions. Well, thank you very much. Let's give everyone a round of applause.