 So, this is the Ruby buff led by Antonio Tercera. Thank you. Okay, good morning, everyone. So, this is the Ruby buff. We are going to discuss our plans and actions for the Jesse release. I think before anything, we can at least be aware of the good work we did with the WISI release. So, we decided to change a lot in the packaging of Ruby libraries and applications. We wrote a new packaging helper based on DH, instead of the old one based on CDBS, and we had to convert a lot of packages. And then you can see here with this green line that we did a very good work. So, by the time WISI was released, we had the 878 packages converted, to not only the new packaging helper, but also to the new naming scheme we created. So, we had, usually, before we had lib full-ruby, and now we have ruby-full, which looks like the Python scheme. And it's, well, everyone in the team thought it was a better naming scheme for libraries. Okay, yeah, so we should be proud of this, and now we have to keep on the good work for the Jesse release. So now, Cedric created a nice to-do list for the Jesse release, and then I organized that page in terms of status, what's the item that has to be done, and then we are going over each item here in this box and try to get volunteers to carry the work, and discuss briefly each item. So, when we do, when we say volunteer to carry the work, it does not mean that the person has to do all the work by themselves, it's just the one responsible for making sure it happens. So, it's more than encouraged for people to seek help for each task of those. So, yeah, first item in the agenda is the ruby-1-h removal. So, ruby-1-h is unsupported upstream already, so upstream drop a support for that version, and we don't have any kind of upstream support anymore. So, we need to drop that from Jesse's app. It's still available on Weezy, but the idea is that we're not going to have ruby-1-h on Jesse. So, then we have a couple of actual items on that front. First, to drop the support on Jim to Deb, which is our package helper. This is done in Git, so we are just waiting for some more information about what fails without ruby-1-h support to upload into the archive. That's with me already. Then we have to identify packages with a hard dependency on ruby-1-h and file bugs, to make sure people know that we are removing ruby-1-h. During that conf I already did a small part of this, so I tried to make sure I could remove ruby-1-h from my system, so I already fixed a couple of packages that were unnecessarily depended explicitly on ruby-1-h. And now we have to catch all the others in file bugs, so if anyone is volunteer to do that, please put your name into the document, in the gobby document, which, by the way, is debconf13-buff-ruby on gobby.debion.org. The next item, or if you are not on gobby, you can tell us on IRC or here, and I will put your name up for it. Then there's the work of tracking the non-leaf package, so stuff that is central to the archive, like Libia-C Linux has ruby-binding, so obviously we can't remove Libia-C Linux. The KDE bindings are still building only for ruby-1-h, so we have to make sure that we don't make sure that those packages are fixed, and then if there are only leaf packages left, we can just request them to be removed if nobody fixed them in time. Yeah, special case here is the KDE ruby-package are still 1-h only. Then we have to identify the packages that are ruby-1-h only and throw them away after we give some time for people to fix them, and then request removal of ruby-1-h. I'm not sure we need to do that in that order, but at least we have to make sure core stuff is not removed because of ruby-1-h. So one idea here, one that I would like our opinions is whether we want to add links and checks for packages depending explicitly on ruby-1-h or even in specific ruby versions. So we should, at this point, we should not be, maybe we should not be allowing packages that require a specific ruby version to work. So any opinions on that? Maybe it depends on ruby-1-h it should be a lintian error and it depends on a specific ruby version should be a lintian warning or something. Okay, yeah, that sounds good. We should also add a lintian check for the old naming schema. Sorry? Is that all right? I hope it is. It's messed up the table a lot, but okay. What Gunnar says on ISE is that specific ruby versions can be a pain but sometimes it works just fine. And interpreter versions last up for several years so he would not suggest dropping altogether support for interpreter versions. So not having multiple versions at the same time? Like Perl does? I think you guys can read that from the back. So Gunnar, we can have multiple versions Okay, so if a package depends on ruby-191 only we should not drop it. I'm not proposing to drop them I just think we should at least warn people. I think, no, I'm not suggesting dropping specific version support just that every package that has a strict dependency on a specific version makes our job of adding support for new versions harder dropping that version in the future harder as well, so my idea is maybe we should allow them but keep a little warning there telling them that that's going to make his life harder and our life harder as well. Or maybe shouldn't it be an error? Yeah, okay. Yeah, if you guys can take notes it's better because I have to keep the flow here. Okay, does anyone else have another point in the ruby-181 removal? Concerns? Questions? I think it's clear that we can't maintain it anymore, right? So let's go. Okay, so next step is other interpreters. So we have a couple of items here. We have ruby-2 which is mostly done in Git. I'm just finishing the last packaging bits to upload, especially if it was to multi-arch. So ruby-2 is going to have multi-arch support. The Jam2Dep support is done in Git, so the Git version of Jam2Dep is already built for ruby-19 and ruby-2 and does not build for ruby-181 anymore. We have to file bugs against packages that fail to build with the new Jam2Dep plus ruby-2 during that camp. David Suarez helped us with a rebuild and then we have the results there. It would be nice to have someone to go over the results and file the appropriate bugs. So one question about that is what is the state that we want in JSC? Do we want ruby-2 plus ruby-193? Or do we want only ruby-2? OK. You have an answer? Yeah, so my idea is to probably make ruby-2 the default but still keep ruby-19 and then for JSC plus 1 remove ruby-19. That's my initial idea. I don't know how long ruby-1.89 is supported by upstream for security support reasons. My impression was that ruby-2 was closer to ruby-193 than ruby-193 from ruby-18. So it might make sense to just drop it as soon as we have reasonable ruby-2 support. It makes our life much easier also for the possible release. Well then the problem is we don't have a freeze date yet so it's likely to be not too far away actually. So, something like the beginning of the summer of next year. OK. Yeah. Yeah, I think let's think about it. I think at least making ruby-2 the default should be a goal. We can even add here. OK. OK. We stop after the filing the bugs. We have also tracked bugs against packages that failed to build from source within ruby-2. It shouldn't be too many. From this rebuild we had 500 something packages and more or less 100 failed to build. But I suspect that most of them was because the lack of ruby-1-8. Because the difference between ruby-1-9 and ruby-2 is a lot smaller than between ruby-1-8 and ruby-1-9 so the transition should be a lot smoother. OK. So, yeah. We also have other interpreters like Rubinius. I did initial packaging should be fine but it's probably already outdated. I didn't have too much time to do that because of the main interpreters so maybe I will do but if someone wants to take it, please do it. We also have JRuby which is horribly outdated. Maybe someone could help talking to the Java. For Rubinius it's still relevant because it doesn't seem to be in the mainstream anymore. The last release is from 2001. 2011. Or maybe it's just that they do everything in Git. They don't even release Star Wars anymore. Yeah. Cool guys. That commits from today in Git. Yeah. Nobody does release anymore. Yeah. I think Rubinius is nice because it's based on LLVM so it has Git compiler and lots of cool features that are probably a lot useful but yeah. We also have to check the situation of JRuby so JRuby currently doesn't use the Ruby packages at all. It has its own library path that doesn't use the Devian packages so we need to we need to Yeah. So Gunnar asks if it's how horrible would be to support Rubinius together with the main competitors. So all those are supposed to be compatible. So actually the Rubinius guys were the guys who started Ruby spec which is kind of a unit test for Ruby implementations which is the main Ruby implementation also today so it's supposed to be compatible so we should not have any problems even if we see extensions so the API should be the same and it should work. So as long as someone does the work I'm not sure if I'm going to be able to do it but as long as someone does the work it should be maintainable. Okay. Any more issues or concerns about new interpreters so David Suarez is actually interested in JRuby and is going to take up that work nice. Thank you. Cool. Yeah, next up is to finish the transition so we did a really good job but we didn't we weren't able to do a transition of all packages so there are still packages building with the old packaging helper and using the old naming scheme of LibyFood Ruby and we have to either bring them to the Ruby chain to finish the transition or NMU them or even remove them from the archive if they are not useful and don't have any reverse dependencies so it would be nice to have someone to look at that and also we at this point we should probably publish actually publish our policy which was written and it should be fine but we never went into the trouble of actually publishing it somewhere in the devon.org website something. It would be nice to have someone else to look at that but yeah, we are using DocBook and that stuff and I think there are a lot of better options for writing in a maintainable way yeah any comments on this item or finish the transition in doubts and questions oh Paul van Tilburg is still here hello we have got some people following you on IRC yeah so Paul if you re re-assume the work on the re-policy it would be fine would be nice or at least take it up okay next item is gentle dev improvements so this is both regular maintenance so there are some bugs there most of them wish list bugs that we have to take care of to either fix them or mark the ones that are not feasible if one fix and this is a nice opportunity to get new people to maintain the packaging helper to reduce the bus factor so today is mostly me doing the maintenance it would be nice to have other people I am willing to mentor anyone who takes that wants to do that there is also a to-do file in the git repository it should be also a good source of ideas for improvements there is a low hanging fruit to integrate auto package tests and have our packages with runtime test so currently gentle devs will run unit tests against the built package if a very small change you can make it run against the installed version so you would gain support for auto package tests and the entire infrastructure that is going to be created around that for automatic testing migrations and stuff like that we also help QA a lot so well I am willing to mentor anyone who wants to do everything in gentle dev we also have here another item automatically built and shipped developer docs it's a nice feature as well so anyone if nobody takes it I probably end up in my hands but it would be nice to have people to help with that does anybody has other changes or complaints against gentle dev now we have some more social items not so much technical ones but still stuff we need to do so first coordination points I think it would be nice if we organized the ruby sprint I maybe not periodic but at least one sprint some reasonable time before the freeze so we can actually do important changes so Lucas suggested doing together with FOSDM close to FOSDM we also have the recently announced UK MiniDeviConf so we maybe could do that there as well and is there someone willing to organize that not you but I think in Paris is usually the place that takes sprints right there's a venue you can quite easily use in Paris but Cédric is in Paris as well I'm not in Paris but Cédric is in Paris so anyone volunteers to organize the sprint well let's let for a sprint to be efficient we would have to focus on something what would you have in mind? probably making sure everything works with ruby 2 so right now we have 100 packages that fail without ruby 1.18 with ruby 2 and then once we know exactly what's the situation then we can probably focus on making sure stuff works with ruby 2 but I also think that the volunteer who takes up this task should also propose a focus and I think we can right now I don't know exactly what the focus should be but I think in one or two months we will be able to know what we need what would be helpful to focus on in this sprint to organize I mean I could depending on when but Paris is not the best for me but I can I mean like it's yeah I think organizing involves designing on the venue so yeah I know then bugging people yeah it's mostly coordination work in the minute making sure figuring out how many resources we need to fly people there or I mean for myself it has to be flying because there's no other way to cross the Atlantic but for us good nurses on IRC that we have a non geocentered sprint so just meet on IRC during a week and yeah it could be that as well have focused communication and development that works but I think there's initial meetings a lot more productive but yeah also for real it's like I can if I'm with people walking on Ruby stuff I can like focus on Ruby stuff otherwise they're all my life and so many volunteer stacks bugging you every single day fix this error do that I'd rather I mean if half of the people can meet in Paris and we can fly you over to Paris let's do that okay next item is organized monthly meetings so yes two people already said that we need those it would be nice and I think it's good to have so and volunteers to do that organized meetings I'm going to do that and then I will propose in the meeting some format for the meetings and some way of doing it that's making it the more productive as possible okay yeah so then we come to the last item which is I call it outreach it's somehow related to lots of discussions we had about getting new people and making sure they know their way through the team tools and practices and it would be nice to have someone to coordinate initiative for getting new people and probably that should be coordinated with the if they generate the environmental initiative so basically it would be someone to talk to Ashish and start doing something about these comments yeah so I think that for many of the things listed on that wiki page there are issues that well it's easy to throw a lot of quite inexperienced people at them so we should clearly try to get people involved through that process and it worked quite well in the past if you look at the ruby team three years ago it's great to see that there are something like 12 people on the goby document yeah nice yeah I think I feel that at least reviewing packages today is under as little manpower than it had before so yeah maybe we just yeah maybe we already just we already have good incoming flux of people and we just want to make sure that those people don't get those people do get answers for the packages and yeah Cedric is saying that we already have many RFS mails on the list yeah you guys are right maybe we just need more people to review packages so even those who are not did easy yet can do that so please if you already maintain packages and please help please help with that yeah and then there is a PR issue we need to ah yeah maybe do some PR about the state of ruby and I was just me and Lunar were discussing this during the hike about and then I had a crazy idea of creating a live to demonstrate ruby on the that that would come with a basic desktop system or depending on the level of bike shedding we could do one for each major desktop system and then coming to everything you need for developing ruby so good text editors, all the tools rails and everything and that and that that's also somehow influenced by the talks about blends and how they help bring people I think the ruby team already has some history of bringing people into Debian maybe that could also help I don't know if there is someone willing to do that anybody has any comment on that it's just a 5 minutes job you just need to know what packages you want and that's it and the rest you can clone the official image configurations and just add your packages and you're done so if you know what packages you want you can just tell me and I'll help you along ok cool yeah but then the question will people actually use that do you think I mean we need to tell people that that exists and then we have to make sure yeah because today when someone asks how to use ruby on Debian depending on where you ask they will say use rvm and install everything from source and I don't know if we care enough about people doing that yeah ok I don't know I'm one communication channel I don't know how many people read it but I do, there's someone doing a ruby weekly news letter someone is doing a ruby weekly news letter and a driver tried to um I don't know come up with a series of blog posts and try to have that covered in the ruby weekly news saying hey come on we can use ruby on Debian or maybe you could show probably some could show that ruby integration stuff which is kind of neat and is often completely overlooked that's I mean it's not because the dvd I would not use it usually what I do when I want to test ruby packages is take a live and use packages from the archive I'm not sure like embedding the packages at least for my use cases is not really interesting yeah my thinking about that was I am subscribed to the Rails Brazil mailing list and there is a lot of people who go there without any idea how to start using ruby so if those people have a dvd image to just install and everything is there already instead of messing with rvm rubygen maybe that would be a good way to get people coming I mean not to people coming to the ruby world to know that they don't need to compile stuff from source they want to but they don't need to and so I don't have hopes of converging the people who are already lost but at least making the new people not go to the dark side would be nice I mean I don't know also how much I've yet to read a good comprehensive short critique of rvm and why you know the problem it has because the approach of virtual and for Python or rvm is problematic to me because at least for upgrades and all I'm not sure if I want to go into criticizing rvm I think people who use operating thesis that don't have proper package managers rvm is perfectly fine for them so I mean it's maybe the best solution for them it's not for people who use Debian because we do have a reasonable package manager so in the past rvm did things like redefining the cd built in the shell I think they don't do that anymore but that's a detail so that was they did some things in a very I think it's not the case anymore today and I don't think we should go there we just have to advertise the good points about Debian that people choose less trolling then yes I would ask people to keep an eye on IRC because the guys are saying good stuff there and maybe we lose it because I can't follow everything yeah just to comment that briefly on the screen when you switch to IRC someone was saying about tasks this one I find very important that Ruby team should have really good tasks not just in the inside I mean in general if it then shows up in the inside that's another thing but so that you can like get in some tasks Ruby or whatever or Ruby development or Rails or whatever and you get all the stuff that you're supposed to get I didn't know you were thinking about the live DVD or whatever but having a task would be much more nicer than the images okay and if you then want to do an image of it then that's very simple anyway okay yeah thanks for the suggestion so we are close to the end and we have six minutes left one question from Lunar about how to handle the query embedding in docs that's a very good question and I think lots of packages have this problem and do you guys think we could work out a way of having that handled automatically by Gen2Dab pair I think you volunteer for the automatic documentation generation do you have an idea about that I don't understand the multiple version since they're generated I suppose just Gunnar can you explain about the multiple version bit that you added because what I do now manually in all my packages is to generate the docs with our doc and then remove jquery.js and link no it depends on live.jsj query and link, sim link doc yeah but that's a mess because every documentation you generate now has that so maybe I think you could try to look at that when you are working on the automatic documentation generation and the code that does that already does this sim link juggling do you ship the doc in a different package or in the same package I broke them out to a separate package but FTPmasters thought that it was waste so now they merge into one package then the problem is that we end up with having like you know 100 ruby package binary package that doesn't have anything related to jquery at all but which depends on jquery just because with doc and that's what you build so it makes sense to have a separate doc package at least more sense maybe also remember that you should never ever depend on live.js jquery because otherwise if you have recomments installed it pulls in a patch and all the shit so you really don't want that yeah that's yeah so I think if you have a few minutes left I would like to ask you a question I have several application to package which are review application for Kali Linux and they tend to use bundle is there any good documentation on the way to package those because right now I have well most of you probably know it but bundle has strict version dependency because well when you generate trouble you have a bundle gamefile.loc or something like that which has precise versions and that do not match what's in Debian so up to now I use the ugly way of bundling the whole bundle in the package that I generate so that I don't have any issue but if I want to upload those to Debian I will have to do it properly but is there any definition of what's is in the case or are you just not using bundle for those okay there is not really documentation that yet so the idea is that you have to check whether the strict dependencies are sensible or not because sometimes it's just because the upstream outer run bundle and then it got the dependencies that the person had installed at that time and usually you don't want the code to depend on how the dependencies were installed what you can do is test if the if it works with the package versions and then override the bundle or even comment that out if you already made sure all packages are all dependencies are packaged and you shouldn't you shouldn't need to use bundle because the main use case of bundle is when you have multiple versions of stuff installed at the same time and then bundle will figure out which gems to load to make sure that what this means patching upstream code because well it's not much but if upstream is unreasonable then we don't have any other option I wish we could I mean one idea for auto package test is to load those gem files and make sure the dependencies that upstream intended are satisfied on Debian so that if it's not we know in advance but then you get to the problem of each upstream wants a different version of something and we don't really package multiple versions of libraries so yeah I think we will need to reach a good way of doing that in the future so I don't have an answer right now but we should okay I think our time is up and we can finish here thanks everyone I think we went to the points that needed attention and if any items has no volunteer yet we will try to find volunteers for them thank you thank you Antonio