 meeting was supposed to be recorded, there's nobody of the video team, so it's 10 o'clock, so I propose that we start. Actually, the number of people that show up in this office is rather limited considering that this team has 112 members. Is there somebody on the team? Who's on this? Who is on the team? Great, so you just want to have the situation approved by the team, right? But you are not amongst the top 10 contributors of the team? No, absolutely not. I'm extremely small area. I was wondering, Jonas is on the top 10, but Jonas Midigal is in the top 10. So actually, I had a couple of things that I had possible of doing in this booth. I propose that we first start with a quick run of an introduction to just see which areas people are interested in, because there's one thing that's covered by the team. Actually, I wanted to discuss on the current state of the situation, but I guess that's more for the team than for people outside of the team, although I'd like to note the numbers which I find frightening. There's a couple of things that I really don't like about how JavaScript is in Devian. There's a lot of embedded packages. The JavaScript ecosystem is different than what we do in Devian, so by the way, for all of these things, I have no answers because I haven't dived into it deeply. I just see stuff on the email list, but that's, I guess, part of my introduction. I'm interested as a package maintainer because my app streams use JavaScript and I just want to depend on the right packages that are shipping embedded stuff. Actually, I have no clue about the app script I don't like. Do stuff in the app script, but it's for the world users, so you have to do it. And indeed, I see a lot of embedded copies. I have some. I admit that. I don't like it. I tend to make new packages for them, but that just means that I add more to the team, because that's the obvious place where I put stuff. And for me, it currently is in the area of jQuery and jQuery-related packages, mostly. Let's mix my introduction with the other agendas and then we'll go to the rest of you. So what I personally also want to learn of what other people are doing in the app script area to make the quality better, such as testing, which is something that I would like to know how to do that, actually. So people have ideas on that. Officially, JavaScript doesn't have any security support, and we think of still doing it, but also that maybe more of a team-related thing, how to handle dependency trees and actually making sure that you can be confident that you don't break half the world, which typically happens, I guess, of course, in any other topics that people have that want to put up. I propose that people just add stuff to the notes if they have comments as well. So what is your interest in JavaScript? My name is Hubert, Hubert Chatty. I'm not really interested in JavaScript itself, but there's some applications that I'm interested in packaging that are JavaScript. So I'm trying to figure out best practices and stuff for JavaScript packages so that I can package those. I actually don't consider myself as a member of the other script team. I'm just beaten as probably several others by these internal copies in my packages and I try hard to get rid of these. I also did some backpots, which also had JavaScript involved. I was just wondering if I was doing the right thing by doing what I'm doing in the Debian mid-team. Just use git-build package and create Debian and Jessie backpots, Debian search backpots bunch and dump what I did there. Push it to the JavaScript component and that's what I'm doing and I just wanted to do it if it's right. Sorry about ruining your point. We can just bother if you like it. We can just tear it all down. And finally I did those team metrics statistics you might be interested in, which clearly proves that the JavaScript team is actually no real team. Yes, I can go into detail if you want to know something about this. Yeah, because I just put the numbers up here of how many members do we have, but it would be interesting to see how many active members we have. Because I worry that that may show quite different picture actually. I guess for me the motivation is quite similar to what we have already had. I have some packages which use JavaScript libraries and most of these are religious embedded copies and I was looking if there's something I could do about that. But yeah, that's pretty much the motivation for showing up here. Hi, I'm Martin Berens. I'm very new to the Debian project, a long time user, but want to still become a maintainer. And I was drawn to this talk or this book because of the problem statement because I'm most interested not in the detail of particular packages, but rather about the overall approach and what strategies people take. So there's all idea of embedded problem, et cetera. It's something that I understand, dependency hell. And I just hope that there's something constructive out of this discussion from that. Hello, I'm Chris. I'm not really packaging any JavaScript related things, but I just stumbled upon the situation of many JavaScript libraries or tools being in active use that are not packaged which is kind of unfortunate when a colleague starts using that and I prefer not to have anything out of the repository installed locally and I just like to understand the situation better. Is this working? Yes. Yes, okay. I'm Antonio Tessero. I adopted the jQuery two years ago. Thank you for that. I'm not particularly fond or excited about JavaScript, but here I am. Anyone around here who is? Hi, I'm Jonas. I help a bit with the Node.js package itself, but very little. I only take blame for that. I don't take any pride for that. That goes to my commentator. And then I maintain the Occlify.js, which is used a lot. I hope it's the best, I believe. And the Leaflet.js and a few more JavaScript libraries. Hi, I'm Ajay. I introduced myself on IRC yesterday and then promptly forgot to look at IRC for the rest of the day. I maintain Pump.io upstream, so I'm not involved in Debian, but I have been meaning to become involved in Debian for like four years now or something. So, yeah. Well, but for four years, right? So we'll see if it happens. But yeah. We have time. Yeah, I would love to see Pump packaged in Debian, and I want to work with the JavaScript team to make that happen and improve tooling around NPM and yada, yada, yada. Hi, what are we doing, intros? Yeah. Okay. Hi, I'm Alana Hashman. I am currently sort of leading the closure team. I am here for two reasons. One, I am kind of curious about targeting closure scripts once we target closure compiling on the JVM. And then also, I am here because I met with one of the release managers of Node and am hoping to sort of figure out the situation with JavaScript and try to make JavaScript in Debian better if that's possible. One of the things that we chatted about was specifically how, I guess, Node upstream is very complicated and apparently uses a vendor-patched NPM, which is one of the reasons that they've had a hard time packaging for Debian or something like that. And so they're apparently looking into doing a very minimal like low dependency installer, which will allow you to like install a user space NPM of their choice. So anyways, curious to hear what's going on. When you say they're looking at doing a small installer... Mike, Mike, please. To clarify, when you say they're looking at doing a small installer, do you mean Node upstream? Yes. Okay. Yes, for the mic. Hi, I'm Jeffrey. I don't currently have an interest in Node.js, but I have one of my last job and will almost certainly have one of my next one. And so I would like to just pay attention to what's happening because I'm curious. Gabriel, student and Debian user. Kind of curious about how all the Node packaging will go. So of the newcomers that were after my first question, is there, how many of you are on the officially member of these 112 people? Not me. Well, Antonio, I guess, but... So actually, this was intended, or at least that was the incentive for me to meet up with my team members, but apparently most interest is not from the team, which actually doesn't surprise me. Just a couple of numbers that I tried to look up. The team maintains about 1,100 packages of which half have a newer upstream version, which sort of describes the extremely awkward position we're in. So I'm not exactly sure how to approach what we need to do or what we could do here. Do people have ideas of what to share of how they approach things regarding JavaScript? Because it's mentioned before. If I understand correctly, I'm not heavily involved in JavaScript. I just try to stay away from it. But I do try to... There's a couple of JavaScript packages that I maintain and that I want to build properly, for instance, where I have a hard time. As far as I read, the biggest challenge is that in the JavaScript ecosystem, there's a lot of micro packages and that doesn't scale very well with how Debian works with packages, with a big copyright file and control files and stuff like that. So, yeah, as I said, in my first introduction as well, I don't have much answers in this box, but I really like to share ideas of what we could do to try and improve this situation. One of the things that I found very scary is I did the last couple of uploads of jQuery Y, introduced a new upstream version, which did break stuff, but I couldn't figure out a better way than just upload and see you having maintainers find out that stuff breaks and have it fixed because I have absolutely no clue how I can properly test this in a way where you cover anything that the package is doing. But as the example of Antonio, I think jQuery was like a couple of years behind in what we had and it was actually triggering a lot of people to embed jQuery in their packages because that's also part of that ecosystem. You just ship it, I mean, typically they're not extremely used files, so you just include them in your package and you're done with it, which from the Debian point of perspective and for security reasons is not very nice way, but typically these kind of things are integrated with the version that upstream ships, so it also doesn't skill very well of having lots of upstreams, which depend on slightly different versions of the JavaScript, and I really have no idea what our answer as Debian should be to this situation also because this team is like, I don't consider it really a team, it's mostly just a name for lots of identities in Debian and you comment on that. I don't have the solution either, but I think as it sounds like you think also that the proper way to do it is that we package things separately from each other so that we can track it properly. Putting it inside another package is the same as you're saying, I package this thing without maintaining it. That's essentially what you're saying when you're making a code copy inside, leaving a code copy inside the source of another package. You are not sharing your packaging with the rest of Debian, which essentially means I'm not going to maintain this thing, I'm not going to reveal to the rest of the project what the ABI of this thing is, because I don't want anyone else to use this. That's horrible. It's very horrible. We might have done so for 20 years before we started packaging jQuery and it might be stuffed in a lot of times before. That's no excuse at all. So the solution is that we package the newer version when ready, but we don't know when ready is. I believe that the important thing here is JavaScript, the JavaScript ecosystem, the JavaScript community, they have something they call the semantic versioning system that not all of packages use, but that's the common norm in this ecosystem. Almost all of them. Sure, yes, it is very, very popular to use NPM and NPM is strongly promoting this, so that's one nice thing about the JavaScript ecosystem that you can whine about a lot of things in JavaScript, but that's one thing that they do. It's a young thing and they're using this semantic versioning system. So if we can then say, assume, one thing I propose is that we assume that packages in Debian, depending on JavaScript packages, we can assume that they are using semantic versioning system, which means that if you don't support a newer version with the same minor, I think it is, then you have to explicitly say that this is very strictly to this micro version, which should be really hard in that situation. And in the same way, you shouldn't bump to a new major version, because then you know things will break. You should then keep the old one or coordinate with existing packages. Things that are very normal in Debian, among library packages, but we don't have this so tight integration, you cannot just rebuild and then things will break clearly to you because we don't have strong test suits. So I just went through our UDD page of the team and actually I noticed that there's an extremely lot of node packages that actually do have an auto package test. So I would love also to learn how you can write a test suite for a, I mean, if Java, a jQuery or jQuery UI, the one that I upload a couple of times, if I can actually test some of the stuff that I depend on, I would be feeling a lot more comfortable because now it's a blind box upload. I can't, I mean, I do this because my package depends on it and actually my upstream says they have a bug open, they open it themselves, they say, we're incompatible with jQuery with UI 112 the one currently in Debian. Basically they have to untangle their code where they embedded the copy, they made lots of changes to jQuery UI files instead of where actually I think they only require style changes so they should do that in a later file and they made already some changes but it's not integrated. Basically they have a bug open that says we're not ready for 112 and still I do it in Debian and I just hope for the best. I have no clue because I don't even know what they mean when they say it doesn't work. Is it just that the number of pixels is not what they want and stuff is slightly disliked? I don't know. And I'm breaking probably all people's packages by next upload and I wouldn't even... So... You are leaving today so we can't... Yeah, you can beat me up after the meeting, that's fine. So I went to look at the page to see what exactly the automated auto package tests are testing and it's just a simple require test so it's Node.js-e-require package name. So basically it's doing few parts in the Java script play. Basically nothing. No, few parts doesn't load code so that's better than nothing but then I think we need to do more than that. I think NPM has a standard command line to run the test. Is it NPM test or something? I don't know, I'm not really... So I believe generally, I don't know specifically for jQuery UI but generally the problem we have with the test suits that Upstream makes for the browser-based tools is that they require commonly some of the high-level, complex things to remote control a web browser or emulate a web browser or pull in this web kit-based custom web browsers and none of those are really reliable. The framework for running the tests are not in Debian either because they are horrible or because they have a huge dependency stack, the same kind of problem we have with NPM itself. So yes, Upstream sometimes are nice and write these test suits also for the browser parts but the browser parts typically has a higher dependency stack. So in principle we can get there by people doing all these... It's a good traffic problem this season. Okay, but a fair share of the packages are not browser-based, right? I mean you have some good number of packages that are not that browser? The target browser stuff? Sure, the issue raised here was the frustration of shouldn't we also enable the test suits for browser-based JavaScript and not only for the server-based JavaScript because the server-based JavaScript is... Some of them is enabled, some of the test suits are enabled exactly because the test suit can be run. The dependency for the test suit is there. So I maintain Autodebate so if anyone that understands that better like is it an NPM test Autodebate? The standard command to run tests, is it an NPM test? Almost always, but it seems to me that the problem here is not that... The problem here is not that we're not running tests. The problem is that jQuery upstream changes API a lot particularly because jQuery in particular is pre-NPM and pre-semantic versioning and so they're like whatever, we have our own thing. And so I mean you can run tests all you want on new versions but then other applications are still going to break because the test suite matches the new version, right? But the point is that if something that uses jQuery has its own test suite then we can know that the new jQuery breaks. Yeah, that's true. Yeah, so the reason why I started doing anything in the JavaScript area is CACTI, which is a web application. And indeed, what I would like to have some test... And currently I do a WGAT recursive run of the whole archive and then I just see that my links work, right? That's already found some problems in the JavaScript area where somebody uploaded a new version and removed the file that I depended on, so that I could see. But I don't know how my package is using it but I would love to learn also that I can actually test that without going into basically reproducing whatever the package is doing in my test suite. One thing I would like to see this team become less afraid of doing is shipping multiple versions of packages in the same way that we ship GTK2 and GTK3 side by side. I mean, obviously this isn't tenable for every single version of a package ever but I can imagine a scenario where we shipped like some... a little somewhat old version of jQuery for applications that haven't been updated to the new version and then the very latest version of jQuery for applications that have or for NPM packages shipping the latest major version and then the major version behind that. I think no one is against that. It only needs the volunteer. It needs someone to maintain. So what I emphasize before is if you stuff it in... A coding is easy. It's the simple part. Packaging is easy. That is what I'm afraid of, of what we as a team or we as a project or a private who's doing... a pirate who's doing the work with this big note stack for an extremely big amount of packages that flow into the archive which is a lot of work to cradle this. But indeed Jonas mentioned it a couple of times on the middle list as well. It's not about the initial upload. That's the easy part even if it's a lot of work. I am curious about how the version... multi-version problem, like what the scale of it is. So how many versions of jQuery are claimed by say the upstreams of the packages in Debian? So assuming for... Assuming at the moment. We don't know because people make code copies. So Debian cannot figure that out. Without having it outside, we cannot really understand the problem. It seems like this is a place where we could be of a significant value to upstream if we were a little bit less pushy about everyone has to be on the same version of jQuery at the exact same time. Which we're not, yeah. I have a specific data point about jQuery because I deal with that. So jQuery is currently using... We have the latest release version with three points something. And before I did that, I issued lots of warnings. People are going to do that. And then after I did that, I received no complaints at all. I saw one. What? I saw one. Yeah? It's so late in the cycle. So my other question about cycle is how much of the upstreams that say, we know we don't work with the new version yet, please hold on. Is happening for tracking packages an unstable versus the version we want in the release? Which is say, is there some room where we have multiple, possibly non-security supported packages during the unstable lifetime and then once freeze is happening or about to happen, that converges into one version? I'm just thinking out loud here and I also, I know other teams have similar problems with their upstreams that want conflicting versions of the same thing and we don't know how to keep them happy. Yeah, currently the whole story is security. It's not covered by security, right? Right. Which is something that I also like to get rid of. I mean, I was triggered to actually... I mean, we could still, as a team, we, the dangerous, I can go word, follow the security issues that are raised for JavaScript, which I don't think we currently do. And we could still provide it, although the security team is not telling us. So on the issue of security, that was one of the things that I wanted to raise. So like I saw a note in the stretch release which said, JavaScript and Node are not supported like with respect to security support because there aren't volunteers. Oh, and I saw that I was like, what? That's what? And so like as a result of that, I went and talked to upstream and I said, hey, upstream, do you have a security team? Because they say they don't have any volunteers. And they said, yeah, we have a security team. We want to help, but we don't know how. So... So I'm not on the security team and I haven't asked them, but what I think, what basically they're saying is, yeah, we do get these CVEs in. I mean, what the security team often just does is contact the maintainers, talk to the maintainers of what needs to happen. But they're not tracking the JavaScript or Node, I don't know exactly where the boundary lives, but they're not tracking that because of past reasons or whatever. I can maybe add a little to that. I believe that the situation specifically for Node.js is that there is one maintainer, which is not me. Jeremy Lall is the maintainer of Node.js and he could use help. So it's not that upstream is slow. That's not the problem here at all. It's not a complaint to upstream. Node.js upstream runs its course and it pays. It's great, probably, I don't know, hopefully. But Node.js in Debian is lagging behind and there's more to it than just packaging what upstream releases. One of the things is that we want to split out libv8 and maintain that properly, which our definition of properly is a different one than upstream is recognizing. We try to package to more architectures than upstream does, or we try to do that at some point at least. So there's difference in what we define as being maintenance in Debian and upstream. So it's additional work than just grabbing the tar balls from upstream. So it's not a complaint to upstream. I think it's more like upstream wants to help with Debian because they see there's that gap, but they just don't know how. One huge thing that has happened recently is we no longer need to be the weird guys in the world of Node.js. We don't need to rename the binary anymore. That's great. People were really happy about that. That created tension, especially for the NPM part of the ecosystem. So that thing is gone. That is in the past. So yes, we could love to have more help if anybody could, but I don't think what it requires is people joining Debian, tuning into the kind of issues we have. The things like convenient code covers in other packages and so how the dynamic is within Debian. It's not coding anything, serving it to Debian. So we welcome more developers and especially the one guy who is hanging on, clinging on to Node.js. He could need some help. Someone who understands the C++ happening in Node.js. I think that is a crucial part. What the security team did half a year ago was saying we can look back at the history for the last half year or so or the last year and we can recognize a pattern of you are very late in responding to the CVEs and we still see that it's lagging behind. So we would like to kill Node.js and not release it for the next Debian release. And we said, no, this is not going to happen. So what they did instead was saying, okay, we release it because you woke up when we warned you, but we will not be responsible for the security of this because it's still lagging behind too much. So that's the situation. The solution is more manpower in Debian. Sounds good. Well, I said I'm not in the Java team, but regarding the more manpower, do we have some kind of team policy where newcomers could read how to behave in the team? Well, we don't have a problem with behavior in the team so we have not tried to restrict people on that. We have a very loose policy. That's also why the team is very loose. What we have a policy is that, no, there is a policy and I will not even dare to say what it is. I haven't looked at the page for a long time. I didn't even know that was one. So I saw that the IRC channel looks at least relatively active, like people respond. Is the mailing list also? Yes, there are people on the mailing list and people will respond. It's not used so much. I don't know why. It was the best way to get in contact. The mailing list is active too. It's just not used that much. But we are people on the mailing list and I think we are more and different people on the mailing list. So what I typically recommend people that come on IRC and then feel that they didn't get a response that happens sometimes is I say, well, use the mailing list because the people who are reflecting more might be the ones who are using mail instead of IRC. I'm not on IRC. To answer my question, I found the policy. It fits on one screen. That's a good thing. Yes, maybe. But you prove that you need more people so maybe it doesn't work to get more people even if it's a good thing to be short. Actually, another point. Am I correct in saying that we mostly have two groups? That's the note stuff and that's the jQuery stuff? Or is that not... I mean, that's just a feeling that I have but I haven't substantiated that. That's an arbitrary split, I think. There are packages running for server, yes, and some of this is C-based stuff, a C++ or whatever it is. But no, I don't think that you can say that that's a split. And others people say that people who really don't give a fuck about JavaScript but have to do it anyway and they just want to throw it in there like yourself. And then there are people who are fumbling and trying to look at this as an ecosystem and trying to build a higher stack, like the people, especially for working on NPM and you would need that for... No, but could. The whole stack. It's a large stack needed for... Push the work on him. I think that the jQuery doesn't need that many dependencies, I believe. Yeah, actually it does. It needs grants to build, so at the time we didn't have grants, so I had to rewrite my own version of the build system. Right, right. Yeah, more or less. But now we have grants for... I copy that for the UI. Thank you for the great example. So now we do have grants, so if anyone is interested, I could hand over jQuery and you could delete everything that I did before and now use the proper build system. It's okay. Okay, so it needs grant plus grant dash, whatever. Yeah, I don't know. So grant itself is there. I don't know if the other things are there. Yeah, I guess... Sorry for interrupting. Indeed, for me also, with grant except when I tried to run it and it didn't work what I tried to do. So indeed people from the ecosystem would help on doing the things because I'm trying it with all my experience from Debian elsewhere. This is just for me a weird, new, nice experience except that I'd like to see it more of a team than just the group of individuals that I now see that would make it also easier, I guess, to do this kind of thing. I've just looked up the JavaScript policy page as well. It is indeed very short, too short. As a result, for a beginner, it doesn't give anything like how to. So I'd say what it's stating in policy is what. In other words, the end result that there should be requirements, a few naming conventions and so on. And that's about all. But this is part of the problem rather than part of a solution. It should be bigger. There should certainly be ways to attract people and to get them started. I'm absolutely not in a position to do that because I really don't have the feeling that I know what I'm doing even in this team. So not even know what the policies should look like. That's okay. I didn't know what I was doing and I revived a dead team. Sorry. I did, too. I picked my other challenges. Did you have anything to share on your metric? I put in the links to the team metrics statistics. Maybe you present the first one. So actually these pages take ages to load because of these thousands of packages that we have. This graph presents the commits for certain packages. So more than 300 packages which have commits only by a single maintainer and you have 150 packages. And they were committed only once, I guess. Well, that's not part of the thing. No, no, no. That's not possible because I'm excluding commits of people who committed less than five times. So random commits are not part of the statistics but these commit at least committed five times. But it's a single maintainer package relation, I think. The ones which are maintained by two persons, maybe one person started and the other person took over and the rest is probably noise. I'm currently calculating the upgrade graphs, but yeah, okay. So if you replace JavaScript there with ruby-extras in the opening into a new tab. Why here? Are we? Yeah, do that in a new tab so you can compare the two. It's probably the same. You should compare with the Perl team. Like this? Yes. Extras with an S. Yeah, so that's the difference between a team that works and a team that doesn't. The Perl team is even more impressive, but this is also quite okay. And what I guess that we are looking at is also an echo of how well-structured is the upstream thing. Not to bash upstream here per se, but upstream way of being well-structured for JavaScript has an oddity that clashes with Debian in the upstream tools. NPM, especially, relies on the network and relies on binary blobs that has copied over and other things that has been cleaned out, especially in Perl-based and I guess also in ruby. Yes, we might interpret this as being, so people are egoistic in the JavaScript team. Yes, that might be true. We can also interpret this as being, this is a different kind of challenge than the teams where they are more well-formed and fitting well to the Debian kind of maintaining packages, putting things into pieces. Just saying. And by the way, about the policy, I will not write the policy. I recognize that, okay, I was wrong. There is no proper policy. Greats that identified. Now we need to find a volunteer. So another area where we need a volunteer. Are we keeping like a, is there like a to-dos page or something on the Wiki where we're documenting all of these gaps? You just volunteered. Okay, so I don't want to... I don't have my own team. Let me clarify. I don't think I will be good at writing a policy, but I will be very happy to have someone pick my brain. I've been along for some time and I think I have opinions and I can maybe share something that even is valuable. I don't know, but I need someone to interpret that or organize those thoughts. So I welcome people picking my brain. I will be available for that. I'm just thinking of more like a page in which someone can go to and see all of the stuff that hasn't been done, like to do right policy. For the list of packages missing or packages wanted and things like that, we have... Yeah, that's all on the bug tracker. In addition to the bug tracker, we have the machinery to try to extract from MPM the hierarchy of which other packages does these things need, trickling down, and then which of these are packaged at the moment in which versions and what is missing there. So we have some machine for that and for specific packages like MPM and a few others, we have then thrown this on a wiki and we reverse these packages sometimes. So that is very machine processed task lists, but we don't have the things like more socially. Okay. Does someone want to write that down as like an action item? I wrote it down here. I guess I can take up the task to create a wiki page of improving Java script team situation. Thank you. So I can start the wiki page and at least dump this information in there and put it on the middle list. I'm not going to drive it further than that, so we can take that as a start point. If anybody is... Well, if there's people committing to at least helping traction the process, because I'm not going to drive this. So ad hoc, like anybody popping up on IRC or anybody dropping a mail on the mailing lists, I can commit to try to be more attentive to these things and respond. That's as much as I can offer here. And one of the things that people can pop up on the mailing list or on IRC to do if they like, they don't even need to maintain packages. They could also contribute with just picking brains of me and others that respond to them and try to put that into the wiki pages. That was also clearly helpful for us, just for the video also. Anybody considering doing help and not daring to maintain... Take over the acreage? They might help another. Just a comment. I got quite some of these... I didn't look at a lot of the packages, but I thought very often these kind of new versions... I mean, it's trivial if the package and the upstream and its minor changes to actually get the new upstream, build it and upload it. I mean, I could do that. You could nearly automate some of the stuff. Not, of course, the final... You need to do some checks. I'm extremely uncomfortable of actually doing that because I don't know what I would be doing. That's not maintenance. We need to round up anybody having a last comment. It doesn't need to be me, absolutely. I was just going to say that as someone who is heavily involved in an upstream JavaScript project and also tracks NPM and node upstream pretty closely, if anyone wants to take a crack at updating the policy, I would love to answer questions like whether things make sense and stuff like that. I don't know, maybe if no one does it, I would eventually do it, but I don't have enough experience on the DB inside yet for... Yeah. One thing that might be very useful is organizing a sprint. So when you get people together physically, it helps a lot to build a sense of team. So you can figure out what other people are willing... would be willing to go to a sprint, do a wiki page, and then figure out what's the best geographical location to do that. And then in Debian has money to pay for that, so... Let's cut it there then. Okay, thanks for coming and joining in the discussion.